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ABSTRACT 


The  Optimized  Network  Engmeering  Tool  (OFNET*)  is  a  commercially  available 
communicatioiis  network  simulation  package.  This  thesis  involves  the  modification  of 
OFNEI^s  Hber  Distributed  Data  Interfiice  Local  Area  Network  (FDDI  LAN)  model  in  order 
to  enhance  its  usefiilness  as  an  aid  in  the  developmem  of  recommendations  for  the 
characteristics  and  metrics  to  be  eventually  ii^uded  in  the  Defense  Service  Project  Office's 
(DSPO)  Common  Data  Link  (CDL)  project.  This  work  includes  a  step-by-step  guide  for 
FDDI  simulation  in  OPNET*,  and  a  discussion  of  the  dumges  made  to  the  original  model  to 
enhance  its  performance  and  data  di^lay  characteristics.  Simple  tests  are  provided  to  verify 
the  con^rleted  modd's  petfiarmance  and  usefiilness  as  a  working  tool  for  further  devdopmem. 
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1.  INTRODUCTION 


A.  PROBLEM  STATEMENT 

The  amulation  modd  described  in  this  thesis  was  devdoped  in  support  of  the  Defense 
Support  Project  OfiBce's  (DSPO)  Common  Data  Link  (CDL)  project.  The  Common  Data 
Link  is  a  fiill  dtq>lex,  jam  resistant,  poim-to-poim  microwave  communication  system  for  use 
in  imagiqg  and  signals  intelligence  collection  systems  (DSPO,  1993,  p.  1).  Essentially,  CDL 
is  to  provide  a  protocol  for  communication  between  two  or  more  Fiber  Distributed  Data 
Interi&ce  Local  Area  Netwoiks  (FDDI  LAN).  These  include  an  airborne  LAN  providing 
sensor  information  with  high  data  transfer  rates,  and  a  ground  based  LAN  providing 
command  and  control  information. 

This  woric  is  concerned  primarily  with  the  modification  and  testing  of  a  commercially 
available  communications  network  simulation  program,  MIL  3,  Inc.'s  Optimized  Network 
Engineering  Tool  (OPNET*).  This  thesis  represems  the  first  portion  of  three  rdativdy 
independent  research  tasks  being  performed  as  MS  theses  to  provide  evaluations  of  several 
Network  Interfiices  (NI)  to  the  CDL  and  a  muhilink  poim-to-poim  protocol,  in  support  of 
the  CDL  project. 


B.  SCOPE 


The  scope  of  this  thesis  includes  the  following; 

»  Introduce  the  CDL  concept  as  the  context  in  uduch  the  FDDI  simulation 
model  is  to  be  modified  and  tested. 

»  Provide  a  tutorial  st^intioducticm  to  the  OPNET*  FDDI  modd,  designed 
to  expand  i^on  the  tutorial  provided  by  die  manuftcturer.  This  is  directed 
to  those  who  will  conduct  fiirther  studies  in  the  CDL  project,  and  also  to 
students  urfiose  dass  labmatory  work  win  include  simulations  in  OPNET*. 
»  Discuss  in  detail  the  modifications  made  to  the  given  model.  Provide 
analysis  of  the  modds  actual  simulation  performance  as  a  validation  of  the 
modd's  usefiifaiess  to  the  CDL  work  at  NPS  through  comparisons  against 
trials  published  in  the  research  literature  using  other  siinulation  tools. 

C.  BENEFITS 

The  primary  contribution  of  this  theds  is  the  devdopmetit  of  a  functioning  simulation 
modd  that  wiU  support  the  features  typicaUy  required  in  a  CDL  deployment  scenario.  Typical 
data  communication  requirements  indude  the  following. 

*’  a  wide  range  of  data  rates, 

»  a  wide  range  of  error  rates  and  types  of  error  correction  required, 

»  real-time  requirements  such  as  user-specified  delivery  delays  and  its 
variation  (jitter). 


2 


»  comecticMi  requiicniefits  (whether  connectioii-orieiited  or  connectionless, 
nuilticasting,  broadcasting,  etc.), 

»  retransmission  requirements, 

»  coupling  and  synchronization  with  other  data  sources,  and 
»  adjustable  prioritization  relative  to  other  sources. 

The  second  benefit  is  to  document  in  detail  the  MIL  3,  Inc.'s  FDDI  LAN  simulation 
model  in  its  operation  and  in  its  modificatiotL  The  third  benefit  lies  in  the  use  of  the 
developed  model  as  an  instructional  tool  for  classroom  laboratory  exercises  supporting  the 
study  of  FDDI  LAN  operation. 

D.  ORGANIZATION 

This  thesis  is  organized  as  follows.  Chapter  n  provides  a  tutorial  on  the  use  of  the 
FDDI  LAN  model  provided  with  OPNET*.  Chapter  m  addresses  the  details  of  the 
modifications  made  to  the  given  model  to  simulate  multicasting  and  priority>based  trafBc. 
Where  ^plicable,  clarifications  r^arding  the  OPNET*  manuals  are  highlighted.  Ciuq>ter  IV 
presents  the  remits  of  simulation  tests  intended  to  verify  the  validity  of  the  modified  model. 
The  thesis  ends  with  conclusions  and  recommendations  for  future  work  in  Chapter  \^ 
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n.  MODELING  AN  FDDI  LAN  IN  OPNET* 

A.  OVERVIEW 

This  chapter  is  intended  to  provide  a  tutorial  on  the  use  of  OPNET*  to  model  an  FDDI 
LAN  by  providing  a  briefsetofsteps  to  buikl  and  execute  a  simulation.  The  current  version 
as  of  this  writing  is  Rdease  2.4.A,  dated  02/27/93,  which  is  the  third  revision.  Rdease  2.4.  A, 
Errata  1,  dated  08/01/93  is  a  manual  update.  Some  prerequisite  knowledge  is  required  of  the 
user,  including  "C"  programming  language  syntax,  ability  to  use  a  UNIX  workstation,  and  an 
understanding  of  the  FDDI  protocol.  MIL  3,  Inc.  provide^  thorough  documentation  in  the 
form  of  an  eleven  volume  set  of  manuals,  the  first  of  which  is  Vol.  1 .0,  entitled.  Tutorial 
Manual  It  includes  a  general  introduction  to  OPNET*,  a  trouble-shooting  guide,  and  five 
chapters  presenting  dififerent  communications  network  modds.  While  none  of  these  discusses 
FDDI  in  particular,  all  are  designed  to  fiuniliarize  the  novice  user  with  the  mechanics  of  the 
user  inteifiu»,  and  should  be  studied  prior  to  working  with  OPNET*.  Volumes  4.0  and  4.1, 
the  Tool  Operations  Manual,  describes  the  editors  of  the  user  interface,  and  should  likewise 
be  studied.  The  chapter  entitled  "FDOI"  in  Vol.  8. 1 .0,  Example  Modeb  Manual,  Protocol 
Modeb,  discusses  the  FDDI  simulation  in  detail,  and  provides  the  essential  information  to 
build,  develop  and  execute  a  simulation.  Most  of  the  information  presented  here  is  available 
in  the  manuals,  but  a  number  of  idiosyncrasies  exist  which  are  not  readily  documented.  These 
required  trial  and  error  experimentation  to  discover,  and  in  many  cases  required  explanation 
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from  MEL  3,  Inc.'s  excellent  tedmical  support  organization.  The  new  user  is  advised  to  heed 
every  sentence  regarding  mechanical  details;  much  of  the  advice  given  is  hard-earned. 

This  thesis  will  not  present  an  explanation  of  the  FDDI  protocol  in  detail,  except  as 
necessary  to  emphasize  or  clarify  the  operation  of  the  modd.  Many  discussions  exist  in  the 
research  literature  and  textbooks,  for  example,  Stallings,  (1991,  1993).  Those  imerested  in 
the  physical  characteristics  of  optical  fiber  systems  are  referred  to  Powers,  (1993).  A  useful 
introduction  to  modeling  FDDI  in  OPNET*  is  Modeling  and  Sinmlation  of  a  Fiber 
Distributed  Ikna  Interface  Local  Area  Network,  a  Naval  Postgraduate  School  MSEE  thesis 
by  Aldo  Schenone,  vriiich  summarizes  OPNET^s  FDDI  modd,  includes  a  detailed  description 
of  the  FDDI  protocol,  presents  the  results  of  several  simulations,  and  ends  with  a  challenge 
to  other  researchers  to  further  devdop  the  modd.  (Schenone,  1993) 

The  renuunder  of  this  chapter  will  briefly  introduce  the  structure  of  OPNET^s  FDDI 
LAN  model  and  its  components,  introduce  some  preliminary  modifications,  then  lead  the 
reader  through  a  simple  simulation. 

B.  PRELIMINARY  THEORY 

1.  Theoretical  vs  OPNET*  Modd  of  FDDI 

The  setting  of  parameters  in  OPNET*  simulations  is  based  on  the  following 
equation  and  discussion,  which  is  found  in  most  literature  treating  FDDI  LANs,  including 
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Powers  (1993.  p.  340).  Stallings  (1993.  p.  225).  Tan.  ct  al  (1988.  p.55).  and 
Jain.  (1991.  p.20).  to  name  a  few: 

DJi4ox  *  F_Max  ♦  TokntTtm*  ♦  ££4^  i  TTRT 

>Kdiere: 

SAf  =  synchronous  allocation  fer  station  i. 

D_Max  =  propagation  time  for  one  complete  circuit  of  the  ring. 

FJAax = time  required  to  transmit  a  maximum-length  frame  (4500  octets),  and 
TokenTime  -  time  required  to  transnut  a  token 

In  an  actual  LAN.  a  station  management  protoad  handles  the  assignments  of  SA,. 
which  mi^  be  changed  in  real  time.  OPNET*  simulations  represent  steady-state  performance, 
and  do  not  comemplate  changing  network  conditions. 

AH  stations  negotiate  a  common  value  of  TTRT.  Also,  these  timers  and  variables 
are  maintained  at  each  station 

-  Token  Rotation  Timer  (TRT) 

-  Token  Holding  Timer  (THT) 

-  Late  counter  (LC) 

Each  station  is  initialized  to  the  same  TRT.  which  is  set  to  TTRT.  Note  that  LC, 
TRT  and  THT  are  not  global;  each  station  maintains  its  own  copies,  which  wUl  differ  from 
those  of  other  stations.  If  a  given  station  receives  the  token  before  its  TRT  has  expired,  then 
that  TRT  is  reset  to  TTRT.  On  the  other  hand,  should  the  token  arrive  after  the  expiration 
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ofTRT,  then  its  leteness  is  recorded  by  setting  LC  to  ”1"  (at  that  station).  Two  consecutive 
late  tdcens  will  increnoent  LC  to  "2",  in  which  case  the  token  is  considered  to  be  lost,  and  a 
re-initialization  process  will  commence.  OPNET*  has  no  provision  for  re-initialization.  On 
the  other  hand,  as  a  con^niterized  simulation,  it  never  permits  LC-2  to  occur. 

When  the  token  arrives  earty,  (before  TRT  expires),  THT  is  set  to  the  current 
value  ofTRT.  The  transmission  rules  are  as  follows: 

1 .  A  station  may  transmit  synchronous  traffic  for  a  time  S A, .  as  specified  for 
that  station. 

2.  THT  is  enabled  after  synchronous  traffic  is  sent,  or  if  there  was  no 
synchronous  traffic  to  send.  The  station  may  transmit  asynchronous  traffic 
while  THT  >  0. 

In  the  TX.DAT  A  state  of  the  MAC  process  model,  THT  is  incremented  fi’om  zero 
to  THT.  This  is  an  irnportam  point  in  regard  to  the  prioritization  scheme  by  which  a  value 
T.Prl  [  1  ]  is  assigned  to  each  priority  setting,  and  the  eligibility  of  a  given  priority  to  transmit 
depends  on  T_Pr  1  [1  ]  in  comparison  to  THT.  That  is,  for  THT  decrementing,  priority  1 
traffic  may  be  transmitted  as  long  as  T_Prl  [1]  is  less  than  THT.  This  implies  lower 
T_Pri  [  i  ]  is  assigned  to  hi^ier  priority.  In  OPNET*,  THT  increments  up  from  zero.  Priority 
1  traffic  may  be  transmitted  as  long  as  T_Pri  [  1  ]  is  greater  than  THT,  implying  that  higho- 
T_Pri  [  1  ]  is  assigned  to  higher  priority.  This  subtle  point  is  important  to  know  \riien  setting 
values  to  T_Pri  [  1  ]  in  the  INTT  state  of  the  MAC  process  model. 

There  is  an  important  distinction  in  the  timing  of  transmission  eligibility  for 
synchronous  and  asynchronous  traffic; 
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»  The  time  !q)ent  sending  synchronous  traffic  may  not  exceed  SA,  for  station 

I.  That  is,  the  protocol  will  not  allow  a  synchronous  packet  transmission 
to  ccmimenceifit  can  not  be  completed  without  exceeding  SA,.  OPNET* 
supports  this  criterion. 

»  Asynchronous  transmissions  may  commence  as  long  as  THT  has  not 
expired.  Any  packet  transmission  in  progress  udien  THT  ejqnres  is 
allowed  to  complete,  but  no  more  will  commence. 

The  protocol  allows  the  actual  token  rotation  time  to  have  a  maximum  val 
(2)TTRT,  with  an  average  value  of  TTRT  over  time. 

2.  FDDI  LAN  Equation  Parameters 

Each  of  the  terms  in  Equation  1  given  above  is  addressed  in  this  section,  with 
reference  to  its  representation  in  OPNEI^s  Environmem  file  attributes. 
a.  •*FJiax” 

The  time  required  to  transmit  a  maximum  length  packet  is  based  on  the 
assumption  that  any  station  is  capable  of  transmitting  at  the  rate  of  100Mbps.  Since  the 
maximum  packet  length  is  36,000  bits  (4500  octets  or  bytes),  the  algd)ra  yields  0.360  ms  for 
F_Max.  Powers  agrees  (1993,  p.  340).  but  Tari  et.  al.  use  0.361  ms  (1988,  p.  55).  In 
OPNET*,  the  fddi.mac  process  model  defines  the  transmission  rate  as  100  Mbps,  in  the 
Header  Block.  F_Max  is  not  directly  assigned  as  an  attribute,  but  simply  exists  as  a  physical 
characteristic  which  must  be  considered  in  determining  TTRT  and  SA,  assignments. 
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The  Maximum  Ring  Latency  is  the  time  required  for  a  frame  to  travel 
around  the  ring.  The  maximum  value  is  often  assumed  in  textbook  discussions,  but  it  should 
be  calculated  for  individual  cases.  The  total  dday  may  be  defined  as  foUows; 

D_Max  -  (total  fiber  length  x  delay  rate)+(nuraber  of 
stations  X  station  latency) 

Powers  uses  1.73  ms,  Tari  et.al.  uses  1.62  ms,  and  Djiceman  and  Bux  use  1.62  ms.  D_Max 
includes  the  time  required  for  a  frame  (which  is  basically  a  number  of  light  flashes)  to  travd 
the  length  of  the  fiber  on  the  ring,  phis  the  time  required  to  cross  each  station  imerfrme. 
5.085  10^  sec./km.  is  the  value  used  in  the  literature  for  the  delay  rate  of  a  signal  in  optical 
fiber.  The  reciprocal  results  in  1.9665eK)8  m/s,  wdiich  agrees  with  the  generally  accepted 
value  of  %  c  for  the  speed  of  light  in  glass.  OPNET*  and  Dykeman  &  Bux  use  a  station 
delay  of  60.0e-08  sec.  Powers  assumes  1  ms  as  a  representative  value.  Ultimately  the  value 
is  a  physical  characteristic  that  could  be  measured  on  a  real  device,  and  may  be  declared  in 
a  computer  simulation.  The  value  1.617  ms  derives  from  using  the  maximum  possible 
dimensions;  500  dual  attachment  stations  or  iOOO  single  attachment  stations  on  a  200  km 
ring  yield  the  following; 

(1000  •  60.0  X  10-“)  +  (200  •  5.085  x  10-“)  =  1.617  ms. 

The  environment  file  attribute  prop_delay  represents  the  actual  time  the 
packet  is  on  the  fiber  between  two  stations,  rather  than  the  delay  rate,  and  therefore  defines 
the  size  of  the  ring.  OPNET*  has  no  safety  feature  to  prevent  the  user  from  entering 


attributes  that  would  define  a  ling  larger  than  200  km.  Note  that  the  stations  are  assumed  to 
be  ecpialfy  spaced.  The  user  should  realize  that  the  value  ofS.08Se4)6  given  with  the  original 
example  environment  file  inq)lies  a  one  Idlometer  length  of  fiber,  rather  than  a  dday  rate. 
Powers  (1993,  p.  328)  notes  that  the  early  proposal  for  FDDI  fimits  fiber  length  between 
stations  to  2  kilmxieters.  In  OPNET*,  the  attributes  prop.delay  and  statlon.latency  are 
used  in  the  "C  code  to  posqxme  the  reception  of  a  packet  until  sufficient  time  has  passed  to 
allow  for  physical  ddays. 

c.  -SAi" 

Syndnrcmous  aOotment,  or  synchronous  bandwidth,  is  the  time  a  station  is 
granted  to  transmit  synchronous  traffic,  regardless  of  the  lateness  of  the  token.  It  is  a  form 
of  prioritization,  providing  a  means  by  whidi  certain  types  of  traffic  are  not  delayed.  For 
exan^de,  voice  trafiGk;  would  be  synchronous.  Textbook  discussions  represent  SA,  in  units  of 
time  for  each  station. 

Asynchronous  traffic  is  transndtted  whenever  there  is  THT  remaining  after 
the  transmission  of  all  synchronous  traffic.  It  is  the  responsibility  of  the  Station  Management 
Protocol  (in  OPNET*,  the  user)  to  ensure  that  the  synchronous  bandwidth  is  sufficient  to 
handle  the  synchronous  ofifered  load.  One  nuuice  involves  the  inviolate  nature  of  SA,  for  each 
station.  A  given  station's  synchronous  offered  load  may  amoum  to  relatively  little  in  terms 
of  bits  per  second,  while  the  packet  size  is  assigned  a  value  too  large  to  be  transmitted  in  the 
time  SA, .  In  this  case,  synchronous  traffic  would  never  be  transmitted,  and  outbound 
packets  would  simply  accumulate  in  the  buffers  of  the  MAC.  The  Environment  file  attribute 
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"sync  bandwidth"  correqiXMids  to  SA„  but  it  expressed  as  a  unitless  frartkm  of  TTRT, 
rather  than  as  a  time. 

d  -TTKT 

Expiation  1  suggests  tiatphysiad  requirements  of  the  fiber  and  the  stations 
are  used  to  determine  a  workable  TTRT  value.  The  FDDI  specification  allows  a  range  of 
settings  fixmi  4  ms  to  16S  ms  (Powers,  1993,  p.  339).  Powers  also  notes  that  synchronous 
voioe  transmission  lequiies  £SAi  « 10  ms.  hi  OPNET*.  the  Environmem  file  attribute  T.Req 
corre^KMids  to  TTRT. 


C.  MODEL  STRUCTURE 

OPNEl^s  FDDI  LAN  modd  structure  is  hierarchical.  The  LAN  is  a  ring  made  of 
stations  and  the  connections  between  them.  Rgure  1  shows  a  SO-station  FDDI  LAN  as 
shown  in  the  user  interfine  window.  Figure  2  is  a  ten  station  ring  provided  for  greater  clarity 
of  detail.  The  stations  are  modded  as  connected  nodes,  each  of  vdiich  is  in  turn  defined  by 
a  process  modd.  The  processes  are  rqiresented  by  state  transition  diagrams,  vduch  are  the 
ultimate  source  of  the  "C"  language  code  that  describes  the  modd's  behavior.  Figure  3 
illustrates  the  FDDI  station  modd.  Figures  4^  are  the  process  models  for  the  source,  sink, 
and  MAC  processes,  re^iectivdy.  These  coire^xmd  one-to-one  to  thenodes  "llc^slnk," 
"nc.slnk,"  and  "mac"  shown  in  Figure  3.  The  packets  ofinformation  that  travd  between 
stations  on  the  ring,  and  between  nodes  within  the  station,  are  also  modeled  and  may  be 
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Figure  1.  SO-Station  FDDI  LAN,  "fddi.net.SO* 


Figure  2.  Ten-Station  FDDI  LAN,  '’fddi_net_10" 
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Figare  3.  FDDI  Station  Modd,  ''fildi_station" 


Figure  4.  Source  Process  Model,  "fddi^gen" 
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FigorcS.  Sink  Process  Modd,  "fddi.smk” 


Figure  6.  MAC  Model,  "fddi_niac' 
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modified.  Model  panuneters  may  be  entered  by  aeveral  methods,  with  the  Enviromnent  fibs 
bemg  by  fiff  the  most  convenient. 

1.  FDDILAN 

Figure  7  diows  e  32>station  FDDl  ring  in  the  user  intefftce  window  as  it  would 
appear  on  a  ccmiputer  screea  This  image  is  displays  the  Netwmic  Editor,  vriiose  icon  appears 
toward  the  upper  left  comer  of  die  figure.  (A  note  mi  the  mechanics  of  activating  the  various 
editors:  as  indicated  in  the  tutorial  manual,  the  center  mouse  button  activates  the  desired 
editm.  If  instead  either  the  left  or  right  button  is  pressed,  then  the  opposite  button  must  also 
be  pressed  to  "cancel"  the  first;  only  then  wiU  the  cemer  button  woric  as  expected).  To  the 
ri^  of  the  ring  are  on-screen  menus  of  attributes  for  one  station  (actually,  three  menus  are 
shown  to  display  simultaneously  all  the  fields).  This  menu  is  invoked  by  placing  the  cursor 
over  the  desired  station,  then  pressing  the  right  mouse  button.  The  FDDI  protocol  supports 
up  to  SOO  dual-attachment  stadons  on  a  ring,  and  OPNET*  permits  firom  two  to  SOO  stations 
in  a  ring. 

Actual  generation  of  the  ring  is  best  done  outside  OFNET*,  through  a  UNIX  command 
window  set  to  the  ""Xop.modelsVfddl"  directory  path.  The  command  "fddl.bulld.em.x 
<number_of_stations>''  will  automatically  generate  an  FDDI  LAN  with  the  number  of 
stations  specified.  The  user  should  verify  that  this  function  is  presem  in  the  desired 
subdirectory.  This  operation  is  described  in  manual  Vol.  8. 1 .0,  "FDDI,"  and  refers  the  user 
to  Vol.  6.0,  External  Interfaces  Manual,  which  has  a  more  complete  description  of  the  ring 
building  protocol.  Were  OPNET*  active  during  this  ring-building  process,  then  the  "Reharii" 
icon  toward  the  lower  right  of  the  user  imerftu:e  window  must  be  activated  to  update  the 
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Figure  7.  Network  and  Attributes  Menus  in  User  Interface  Window 


16 


program's  access  to  iiKxtels  in  the  subdirectory.  In  getMial,  the  "Rehash"  conunand  should 
be  used  frequently,  particularly  v«dien  new  files  are  genaated  through  siinulation  rtins  or 
through  model  editing. 

The  LAN  as  shown  is  not  actually  a  true  ring  architecture,  as  no  dedicated 
physical  layer  object  exists  in  OPNET*  for  modding  ring  architectures.  The  model  is  in  fret 
a  circle  of  point-to-point  links;  the  ring  is  an  abstraction  whose  characteristics  and  behavior 
are  represented  in  the  "C  programs  dtat  comprise  the  process  models.  (OPNET*,  Vol.  8. 1 .0, 
"FDDI,"  p.23) 

2.  FDDI  Station 

Figure  8  illustrates  the  FDDI  station  in  die  user  interfree  window,  summoned  and 
printed  from  the  Node  Editor.  Also  shown  are  the  menus  listing  the  attributes  associated  with 
each  part  of  the  station  model.  Message  traffic  in  the  form  of  packets  is  generated  at  the 
source,  1 1  c_s  rc .  at  a  rate  specified  by  the  user.  The  source  model  does  not  fimetion  as  a 
true  Logical  Link  Control  (LLC)  beyond  correctly  interfreing  with  the  Medium  Access 
Control  (MAC)  model.  (OPNET*,  Vol.  1.0,  "FDDI,"  p.  21)  The  MAC  entity  is  represented 
by  mac  in  the  model,  and  is  responsible  for  encapsulating  packets  generated  by  the  source, 
holding  these  packets  until  they  can  be  transmitted,  receiving  packets  from  other  stations, 
destroying  padeets  as  needed,  and  maintaining  the  locally  held  Token  Holding  Timer  (THT) 
and  Token  Rotation  Tuna-  (TRT).  Packas  are  counted  and  statistics  gathered  at  1 1  c_s  1  n  k. 
These  three  nod»  are  modded  in  detail  by  respective  process  models,  which  may  be  assigned 
with  the  attributes  menus  shown  in  Figure  8.  The  field  "process  model"  may  be  changed 
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Figure  8.  FDDI  Station  Model  with  On-Screen  Attributes  Menus 
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by  cursor  action,  with  sdecdon  made  fixnn  the  resulting  submenu  presenting  a  list  of  available 
process  modds.  The  nodes  "phy.rx**  and  "phy.tx"  represent  the  receiver  and  transmitter 
interfiices  to  the  ring,  and  are  not  further  defined  by  process  models. 

The  user  may  modify  the  station  model  within  the  Node  Editor  by  setting  the 
attributes  fields  as  desired,  then  saving  the  model  by  activating  the  ”wrl  te  node  model " 
icon  toward  the  lower  left  comer  of  the  user  interfiu:e  window.  By  then  exiting  the  Node 
Editor,  entering  the  Netwoiic  Editor,  and  calling  the  desired  networic  model  (e.g., 
''fdd1_net_32"),  eadi  station  acquires  the  new  setting  when  the  networic  model  is  archived 
and  bound  ("A-t-B"  icon).  The  same  modification  may  be  effected  fi'om  within  the  Networic 
Editor  by  calling  the  attributes  menus  for  each  station  and  setting  them  individually.  This 
method  would  be  preferred  only  if  the  user  de^es  to  set  differing  attributes  in  various 
stations.  Note  that  setting  the  attribute  fields  is  not  the  same  as  modifying  the  process  model 
itself,  which  is  accomplished  with  changes  to  the  "C"  programming  code  accessed  through 
the  Process  Editor. 

3.  Processes 

Process  models  are  specified  by  State  Transition  Diagrams  (STD)  representing 
the  actions  of  the  nodes  within  the  station  model.  Figure  9  illustrates  the  process  model 
f  dd1_mac  as  it  appears  in  the  Process  Editor  in  the  user  interface  window.  Figure  10  shows 
the  on-screen  menu  that  appears  when  the  cursor  is  placed  over  one  of  the  states  (ENCAP 
in  this  case),  and  the  right  mouse  button  pressed.  Invoking  the  "enter  execs”  attribute  calls 
the  text  editor  shown  in  Figure  1 1 .  Here  the  user  may  inspect  the  programming  code  behind 
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Figure  10.  Process  Model  "fiddi_mac”  with  On-Screen  Attributes  Menu 


Figure  11.  Process  Model ''fiddi_iiiac"  with  Text  Editor 
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the  modd's  bdiavior,  and  modify  it  if  desired.  Each  state  has  its  own  section  of  code,  and  the 
icons  to  the  left  of  the  window  include  additional  editors,  all  described  in  Vol.  4.0,  Tool 
Operatiwis  Manual.  These  are  primarily  variable  and  fimction  declaration  sections.  The 
entire  code  for  the  process  may  be  caUed  with  the  icon  ".C,"  but  this  editor  is  for  viewing 
only.  Any  changes  made  in  the  ".C"  editor  will  remain  when  the  editor  is  dismissed,  but  will 
disappear  if  the  process  is  compiled.  If  calling  the  ".C  editor  returns  a  ".C  file 
unaval  1  abl  e"  message,  then  recon^iiling  will  generate  the  file  again  (sbcth  icon  above  the 
lower  "EXIT"  icon  in  die  Process  Editor).  Mai^  UNIX  stations  include  a  cleanup  comnuuid 
that  deletes  certam  temporary  files  upon  log^ng  out  of  the  ^rstem,  and  the  "C  language 
codes  ending  r.  '.c”  are  not  necessary  once  simulations  are  generated.  They  may  always  be 
recovered  by  recompiling  the  models.  (In  the  file  directory  containing  OPNET*,  the  model 
sourcecodeshavethesufiBx  ".pr.m".)  Ifchanges  are  made  (in  a  proper  editor),  the  model 
must  be  recompiled.  If  several  changes  are  bdng  made  within  different  sections,  each  may 
be  saved  with  the  keystrokes  <CTRL+S>,  deferring  compiling  to  the  end.  (The  set  of  numuals 
includes  a  summary  page  of  OPNEI^s  text  editor  keyboard  commands.)  If  derired,  the 
model  may  be  saved  without  compiling  by  using  the  "Wri  te  Process  Model "  icon.  When 
a  process  is  changed,  the  station  model  in  the  Node  Editor  must  also  be  called  and  written 
afiesh.  Then  the  corresponding  network  model  must  be  called  into  the  Network  Editor,  and 
be  archived  and  bound  again.  If  the  modified  process  was  not  compiled  earlier,  then  the 
"C+A-*^”  icon  will  compile  all  the  process  models  in  addition  to  archiving  and  binding  them. 
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OL  Source  Node 


The  source  node  of  the  FDDI  station  modd  ^nerates  packets  at  a  rate  and 
size  specified  by  the  user.  It  also  determines  the  destination  address  for  each  packet,  the 
imority  if  applicable,  and  records  the  packet's  creation  time  so  that  dday  statistics  can  later 
be  gathered.  These  data  are  passed  to  the  mac  for  encapsulation.  In  the  Node  Editor,  the 
source  is  labelled  "llc.src."  and  the  process  model  is  "fddl.gen.” 

In  the  source  process'  original  form,  as  rdeased  by  MIL  3,  Inc.  in  version 
2.4.A,  the  packet  arrival  (generation)  rate  is  stochastically  assigned  on  an  exponential 
distribution  approximating  that  specified  by  the  user.  If  a  precise,  invariant  arrival  rate  is 
desired,  it  may  be  assigned  with  the  following  change  to  the  INTT  state  in  the  Process  Editor, 
wdiere  'constant*  is  substituted  for  'exponential*  in  the  line; 

1nter_d1st.ptr  -  op_d1st_load  ('exponential*,  1.0  / 
arrl val_rate,  0.0):. 

A  voice  trafBc  transmitter  station,  for  example,  would  require  a  constant 
packet  arrival  rate  fiom  the  source.  Similariy,  packet  length  is  originally  assigned  a  constant 
value  in  the  given  modd,  but  may  be  set  to  a  stochastic  approximation  of  the  requested  value 
by  replacing  <  ’constant  *>  with  <  ’exponentia  7  *>  in  the  line: 

len_d1st_ptr  -  op_d1st_load  (’constant,*  mean  pk_len, 

0.0); . 

If  all  stations  on  the  ring  are  to  have  the  same  assigned  attributes  and  the 
same  source  code  O-e.,  all  <  'constant  *>  or  all  <  'exponentia  1  *>),  then  the  remaining  steps 
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are  to  save  and  con^ale  the  process  in  the  Process  Editor,  dwn  call  and  save  the  station  modd 
in  the  Node  Editor,  and  finally  archive  and  bind  the  rdevant  LAN  modd  in  the  Netwoilc 
Editor.  If  the  stations  on  tltt  LAN  do  not  all  have  identical  source  code  (i.e.,  some 
'constant*  and  others  'exponential'),  then  the  modified  process  modds  and  their 
corresponding  node  models  must  be  renamed.  The  following  steps  illustrate  the  creation  of 
a  station  modified  to  allow  a  ring  to  simulate  a  number  of  voice  stations  amid  other 
transmitters. 

1.  In  the  Process  Editor,  substitute  'constant*  for  'exponential*  in  the 
"f ddl.gen*'  modd's  INTT  state  editor.  Save  the  change  by  keying  <CTRL+S> 
w^e  the  cursor  is  indde  the  INTT  state's  editor. 

2  Use  the  "Write  Process"  icon  to  save  the  modified  process  under  a  new  name, 
for  example  fdd1_gen_const . 

3.  Con^ile  the  new  process  model,  then  exit  the  Process  Editor. 

4.  The  Node  Editor  is  used  to  create  and  save  a  new  station  model,  by  calling  the 
original  modd  and  changing  the  "process  model "  fidd  in  the  on-screen  menu 
for  the  rdevant  node  On  this  example  the  "fdd1_gen"  process  in  the  1 1  c_s  re 
node  is  changed  to  "fddi_gen_const"). 

5.  The  new  model  is  saved  by  invoking  the  "Write  Node  Model”  icon.  Exit  the 
Node  Editor. 

6.  In  the  Netwoilc  Editor,  the  desired  stations  on  the  rdevant  LAN  are  reassigned 
using  the  on-screen  menus:  when  the  "model "  attribute  fidd  is  invoked  at  a 
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pardcuiar  station,  a  list  of  avail^le  station  models  appears,  and  the  desired  one 
is  chosen.  If  the  expected  model  does  not  appear  in  the  list,  activate  the  User 
Interface  >^indow  "Rehash"  icon  to  refresh  OPNEl^s  access  to  recently 
created  files. 

7.  Desired  stations  are  reassigned  as  required,  and  the  LAN  is  saved,  then  re¬ 
archived  and  bound. 

8.  Difoently  named  models  using  the  same  fimctions  nuiy  cause  naming  conflicts 
at  simulation  run  time.  Should  this  occur,  then  the  word  "statl  c"  must  be 
inserted  in  the  Function  Blocks  ("FB"  icon)  of  both  the  original  and  the  new 

source  model  processes  in  the  Process  Editor,  just  prior  to 
fdell.gen.schedul  e( ) . 

The  above  steps  illustrate  a  change  made  to  the  source  code,  and  do  not 
represent  the  same  situation  in  which  idemical  stations  are  assigned  different  values  in  the 
given  on-screen  attributes  menus. 
b.  Sink  Node 

The  11  c_s  1  nk  node  of  the  station  model  is  the  final  destination  of  all 
message  traffic.  The  INTT  ^e  establishes  counters  to  hold  statistical  information  regarding 
network  perfomumce  (throughput  and  delay).  The  STATS  state  updates  these  counters  as 
packets  are  received.  The  DISCARD  state  reports  the  statistical  infoimation  at  specified 
intervals,  and  finally  destroys  the  packet.  Because  new  packets  are  created  for  each 
transmission,  they  must  eventually  be  destroyed  when  received,  or  the  host  computer 
conducting  the  simulation  will  soon  fill  its  memory. 


26 


The  "fddl.slnk"  modd  in  the  current  version  of  OPNET*  (Rdease 
2.4.  A.  dated  02/27/93)  is  defective.  It  will  cause  the  simulation  to  abort  upon  con^)letion, 
with  the  error  mnsage  "Program  Abort:  packet  pointer  Is  NIL."  in  the  event  any 
station  did  not  recdve  traffic.  Figure  12  illustrates  the  State  Transmission  Diagram  as 
originally  given,  and  the  corrected  version  is  shown  in  Figure  13.  The  user  diould  correct  the 
defective  version,  referring  to  Vol.  1.0,  Tutorial  Manual,  "Bpt,”  pp.6-10.  Saving  this 
modification  requires  the  same  steps  described  for  the  source  modd,  with  the  exception  that 
no  text  has  been  changed.  This  defect  and  its  correction  are  documoited  by  Mil  3,  Inc.  as 
OPBUG2070. 

MIL  3,  Inc.  maintains  an  dectronic  bulletin  board  containing  information 
on  model  corrections  and  upgrades  between  OPNET*  revisions.  Users  may  acquire  these 
upgrades  using  file  transfer  protocol  (ftp)  procedures  to  download  desired  files.  Appendix 
A  includes  a  sample  of  dialogue  used  to  acquire  an  upgraded  file  fi'om  MIL  3,  Inc. 
c.  Medium  Access  Contnd  (MAQ 

The  MAC  process  model  enc^sulates  fiames  recdved  from  the  source 
node  for  transmission  to  other  stations,  maintains  token  holding  and  token  rotation  timers, 
inspects  recdved  packets,  decapsulates  recdved  firames,  and  determines  token  usability. 
Vol.  8. 1 .0,  Example  Models  Manual,  "FDDI,"  provides  a  detailed  description  of  the  MAC 
process  and  of  the  functions  of  its  componem  states. 

The  MAC  model  provided  with  OPNET*  Version  2.4.A,  (filename; 
"fddl.mac.pr.m")  has  been  upgraded  by  MIL  3,  Inc.  and  the  newer  model  and 
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Figure  12.  Original  (Defective)  Sink  Process  Model 
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Figure  13.  Corrected  Sink  Process  Model 
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documentation  are  available  via  ftp  on  Imernet,  under  the  subdirectory 
"''/patches/2.4.B/opbug_2081".  When  retrieving  a  file  via  ftp,  the  user  should  verily  the 
entire  file  is  received  by  checking  the  file  size  listed  on  the  bulletin  board  against  tlw  size  of 
the  file  received.  Entering  <  'type  image  ">  at  the  ftp  prompt  should  ensure  a  full  and  intact 
file  retrieval.  The  original  "f  ddl.mac .  pr  .m"  file  is  then  removed  fi-om  the  user's  directory 
(~/op_models^ddi),  stored  in  a  safe  place,  and  replaced  with  the  newer  version.  The  new  file 
must  then  be  compiled  fi’om  the  command  window  with  the  command,  <  'op_mkpro  -m 
fddi_mac  ’>,  the  procedure  for  udiich  is  described  in  Vol.  6.0,  External  Interfiles  Manual, 
"Env".  It  has  been  observed  that  the  "drag  and  drop"  method  of  transferring  files  in  using  the 
File  Manager  in  the  SunOS  Windows  environment  sometimes  causes  the  subject  file  to  gain 
or  lose  a  byte  or  two,  leading  to  "bltsum  error"  messages  when  said  file  is  compiled  in 
OPNET*.  Standard  UNIX  commands  are  the  most  reliable  method  for  moving  OPNET* 
source  files. 

The  patch  is  not  necessary  to  operate  the  simulation;  it  is  a  refinement  of 
the  model,  and  will  be  included  in  the  next  revision  of  OPNET*.  The  patch  OPBUG  2081 
actually  includes  three  repairs,  documented  as  OPBUGs  2081,  2095,  and  2097.  OPBUG 
2081  corrects  existing  timing  and  efiSciency  inaccuracies  connected  with  the  token 
acceleration  feature,  by  which  the  token  is  destroyed  and  the  simulation  enters  a  "fest 
forward"  mode  in  order  to  reduce  the  number  of  events  while  no  station  has  a  need  to 
transmit.  In  a  real  FDDI  LAN,  TRT  is  reset  each  time  the  token  passes,  whether  or  not  the 
token  is  used.  The  modd  in  its  original  form  allows  the  TRT  timer  to  continue  running  when 
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the  siinuhaicHi  enters  "token  acceleration,"  resulting  in  un«q)ected  Late.Count  occurrences. 
OPBUG  2095  is  also  related  to  the  token  acceleration  fieature,  correcting  the  existing 
inconect  initialization  of  several  variables  when  the  simulation  entos  token  accderation.  In 
particular,  the  variable  Fdd1_Num_Stati  ons .  the  number  of  stations  on  the  ring,  is  always 
reset  to  one,  upsetting  calculations  predicting  the  proper  location  of  the  token  at  the  end  of 
an  idle  period.  Finally,  OPBUG  2097  addresses  the  fact  that  the  original  model  neglects  to 
properiy  account  for  the  transmission  delay  associated  with  the  token  itself 
4.  Packets 

All  communications  between  stations  in  a  LAN  and  between  the  internal  nodes 
of  a  station  are  conducted  using  data  fiamed  into  packets.  The  Parameter  Editor,  described 
in  Vol.  4.0,  Tool  Operations  Manual,  "Pm,"  is  illustrated  in  Figure  14,  which  shows  the 
packet  structure  fdd1_mac_f  r .  which  is  used  to  encapsulate  the  frames  generated  in  the 
Source  node  and  sent  to  the  MAC .  Appendix  B  lists  the  five  packet  structures  used  in  the 
FDDI  LAN  simulation,  giving  their  fields  and  assignments.  OPNET*  simulation  does  not 
enforce  limits  on  packet  size  required  by  the  standard  IEEE  802.S. 
a.  iCI  Formats 

Interfiu:e  control  information  packets  (ICI)  are  used  for  internal 
communication  within  a  station,  reporting  for  example  service  options,  error  conditions,  and 
packet  arrivals.  Figure  IS  shows  the  ICI  Editor  within  the  Parameter  Editor,  with  the  ICI 
fddl_mac_req .  This  ICI  specifies  the  control  information  passed  from  the  source  to  the 
MAC  when  transmission  requests  are  generated.  The  ICI  f  d d  1  _nia  c_i  nd  specifies  control 
information  passed  fiom  the  MAC  to  the  LLC  when  a  packet  has  been  received  by  a  station. 
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Figure  14.  Packet  Format  "fddi_mac_fr"  in  the  Parameter  Editor 
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Figure  15.  ICI  Fonnat  "fd(ii_nuu;_rec"  in  Panuneter  Editor 
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For  OPNET*  sbnulation  purposes,  both  stnictures  are  created  once  per  station  in  the 
simulation ,  and  reused  as  needed. 

b.  Packet  Formats 

Three  types  of  packet  fran^  formats  exist  in  OPNET*  to  simulate 
communications  between  the  stations.  For  the  simulation  these  are  created  as  needed  and 
destroyed  when  no  longer  needed.  Packets  of  format  "f  dd1_1 1  c_f  r”  are  created  in  tin  LLC 
source  as  arrivals  are  generated.  The  format  has  only  one  field,  containing  the  creation  time, 
v^Mch  is  used  to  generate  delay  and  throughput  statistics  when  the  packet  is  fiiully  received 
at  its  destination  address.  The  packet  format  "fddl.mac.fr**  is  used  in  the  MAC  state 
ENCAP  to  encapsulate  the  generated  packets  fix’ transmission  (»  die  LAN.  The  "info"  fidd 
contains  the  "fddl.l  1  c_f  r"  structure  providing  the  data  of  imerest.  Because  OPNET* 
simulates  only  the  characteristics  of  transmission  and  not  the  actions  of  stations  in  response 
to  information  received,  the  packets  used  are  not  precise  replicas  of  real  FDDI  fiames.  The 
token  is  represented  by  the  fiame  format  "fdd1_inac_tk”.  The  field  "fc"  is  inspeaed  by 
each  MAC  process  receiving  a  packet  to  determine  whether  it  is  a  token  or  a  message  packet. 

5.  Environment  File 

y^ipendix  C  is  an  example  of  an  environment  (or  configuration)  file  used  to  assign 
station  attributes  to  a  32-station  FDDI  LAN.  Inspection  shows  that  the  fields  specified  in  the 
file  corre^nd  to  the  "promoted"  fidds  in  the  on-screen  attributes  menus  that  appear  in  the 
Network  and  Node  Editors,  and  to  the  fields  in  the  Simulation  Editor.  Promoted  attributes 
may  be  assigned  directly  within  these  editors,  a  tedious  and  error-prone  process  at  best.  If 
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8  amulation  is  begun  with  none  of  these  attributes  specified,  OPNET*  will  prompt  the  user 
for  inputs  at  the  command  screen,  another  enor>pione  and  tedious  process.  The  environmem 
file  is  the  most  e£Bdent  way  to  assign  parameters  of  interest,  and  may  be  quickly  modified 
between  simulations,  using  the  UNIX  text  editor.  Vol.  6.0,  Ejoemed  Imerfaces  Manual, 
"Env,"  discusses  the  environment  file,  and  points  out  that  attributes  assigned  in  the 
environment  file  supersede  those  assigned  in  the  Node  and  Network  Editors.  The  file  is 
recognized  to  OPNET*  by  its  " .  ef "  sufBx.  The  asagned  attributes  are  described  in  chapter 
TDOr  of  manual  Vol  8.1.0,  Exanple  Models  Manual,  and  are  presented  here  in  their  order 
of  appearance  for  summary  and  in  some  cases  for  required  elaboration.  The  attributes  are  not 
declared  as  variables  in  the  "C"  programs,  but  rather  are  generated  by  adding  them  to  the  on¬ 
screen  menus  in  the  Node  and  Netwmk  Editors.  The  user  can  create  new  attributes  by  adding 
them  to  the  ** extended  attrl  butes”  field  in  the  Node  Editor,  then  including  them  in  the 
environment  file.  This  procedure  is  discussed  in  Chapter  m.  "Env,"  pp.33*34,  in  the 
Eternal  Interfaces  Manual  discusses  the  use  of  name  wildcards  in  the  attributes  given  below. 
Sequence  of  entries  is  not  significam  in  the  environment  file. 
a.  ” station jaddress" 

This  attribute  is  required  for  station  identification,  numbering  of  stations 
is  from  zero  to  N  - 1 ,  where  N  is  the  number  of  stations  on  the  ring.  The  INTT  state  in  the 
MAC  process  calls  this  variable.  Note  that  for  quick  changes  to  the  file,  lines  may  be 
commented  with  the  pound  key 
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h. 

This  attribute  identifies  the  ring,  in  the  event  more  than  one  may  be 
modeled  simuhaneously.  It  is  set  to  zero  if  there  is  only  one  ring. 
e.  "Unv  dest  address" 

This  attribute  assigns  the  lowest  identification  address  that  may  receive 
trafScfiiom  this  station.  The  use  of  the  wild<ard  asterisk,  shown  in  Appendix  C,  assignsthe 
same  value  to  all  stations.  Quotation  marks  are  used  here  because  the  attribute  assigned  has 
spaces  vice  underscore  marks  between  words. 
d  "high  dest  address" 

This  attribute  assigns  the  lugh  end  of  the  range  of  addresses  to  which  a 
station  may  send  trafiBc.  It  is  used  in  conjunction  with  the  previous  attribute  by  the 
"1 1  c.src"  process  in  the  INTT  state.  It  is  permissible  to  limit  the  range  of  target  addresses, 
down  to  one,  but  all  target  addresses  must  lie  in  a  contiguous  sector.  For  example,  the  code 
as  given  has  no  provision  for  allowing  a  particular  station  to  send  packets  to  two  different 
stations  without  also  possibly  sending  to  the  stations  between  them. 
e.  "arriva!  rate" 

This  attribute  assigns  the  rate  at  which  the  source  process  will  generate 
packets,  and  it  is  called  by  the  INTT  state.  It  may  be  set  to  zero  for  any  station  intended  to 
be  idle.  As  originally  used  in  the  process  code,  arrival  rate  is  a  stochastic  approximation 
eqoonentiaily  distributed  about  the  assigned  value.  To  make  this  a  precise  unchanging  value, 
as  in  the  case  of  a  synchronous  voice  transmitter,  the  code  would  have  to  be  modified  as 
described  in  the  previous  discussion  of  the  source  process. 
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/  '^meoH _pkjem 


Mean  packet  length  is  expressed  in  bhs.  Despite  the  name,  this  value  is 
actually  hdd  constant  by  the  INTT  state  of  the  source  process  model.  The  user  may  modify 
the  code  using  the  procedure  described  earlier  to  substitute  < 'exponential  '>  for 
<  'constant '>  in  the  line: 

len_d1st_ptr  -  op_d1st_load  ( 'constant,'  mean  pk  len, 

0.0). 

which  ippears  toward  the  bottom  of  the  INTT  state  enter  executives  in  the  Process  Editor. 
Then  the  station  will  generate  non-identical  packets,  which  may  be  more  realistic  behavior. 
OPNET*  will  permit  any  number  of  bits  for  the  packet  length;  the  user  should  know  that 
FDDI  packets  have  a  maximum  size  of 36.000  bits. 
g.  "asyiur^mix” 

FDDI  stations  may  generate  synchronous  and  asynchronous  traffic.  This 
attribute  sets  the  proportion,  with  1.0  indicating  all  asynchronous  traffic  generated  by  the 
given  station,  0.5  indicating  halfsynchronous  and  half  asynchronous.  Any  value  between  zero 
and  one  inclusive  may  be  chosen.  The  INTT  sute  in  the  n  c_s  rc  model  calls  this  attribute 
with  the  statemem. 

op_1ma_obj_attr_get(my_1d.  'async_m1x".  &async  'nix); 
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k.  "^mehmMdA" 


This  attribute  is  used  in  the  MAC  process,  INTT  stat^  where  it  is  eiq^ressed 
as  a  percentage  of  TTRT.  It  is  analogous  to  SA^  in  Equation  1,  but  is  numerically  a  fraction 
of  T.Req  (TTRT),  while  SA^  is  an  amount  of  time.  Synchronous  bandwidth  should  not  be 
confiised  with  synchnmous  ofiered  load.  Bandwidth  is  esquessed  in  time,  while  synchronous 
offered  load  is  a  bit  transmission  rate.  Therefore,  synchronous  bandwidth  is  the  time  allotted 
for  the  transmission  ofsynchronous  offered  load.  It  is  entirdy  possible  to  set  parameters  so 
that  these  two  attributes  do  not  match  well. 

Indescribing  "sync  bandwidth."  \c\.%AXi,ExcmipleMo(kkKknual, 
"Fddi",  warns  the  user  not  to  allow  the  sum  of  all  assigned  attributes  "sync  bandwl  dth" 
to  exceed  one,  since  OPNET*  does  not  enforce  FDDI  protocol  standards.  However,  this 
warning  neglects  to  consider  the  phyacal  ddi^  parameters  in  Equation  1,  wdiich  indicate  that 
total  synchronous  bandwidth  must  be  some^diat  less  than  TTRT.  The  correct  assignment  of 
"sync  bandwl  dth"  involves  some  algebra,  and  is  pertuqrs  best  erqrlained  with  an  example. 

Given.  D_Max;  1.617  ms. 

F_Max:  0.360  ms. 

Token_Time:  0.00088  ms. 

TTRT:  8.0  ms. 

Using  Equation  1  yields: 

8.0  ms.  -(1.617  ms.  +0.360  ms.  +0.00088  ms.)  =  6.021 12  ms.  =  ESAi 

This  is  6.02112  ms.  of  total  bandwidth  to  be  divided  among  as  many  stations 
assigned.  Assume  there  are  five  such  stations: 
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6.021 12  ms.  5  stations  *  1.204224  ms  *  SA, 

SAf  is  converted  to  "sync  bandwidth"  widi  a  division  by  TTRT: 

1.204224  ms.  8.0  ms. «  0.1S0S28 
This  is  the  value  entered  into  the  Environment  file. 
i  •*T_Req*' 

This  atnftute  is  called  in  the  MAC  process.  INTT  state,  and  represents  the 
specified  station's  requested  value  of  TTRT.  A  real  FDDI  LAN  has  a  TTRT  negotiation 
phas^  (XPNET*  simply  diooses  the  smallest  T.Req  value  available.  The  user  may,  but  need 
not  set  diffident  values  to  eadL  This  value  is  in  units  of  seconds,  which  is  not  apparem  from 
the  manuals  nor  from  the  defiuih  value  that  appean  at  the  command  pronqn  if  no  value  is 
assigned. 

J.  statioH** 

The  spawn  station  is  simply  the  starting  poim  fi^r  the  token,  and  may  be 
assigned  to  any  station  on  the  LAN. 

k.  "stationJUaeiuy” 

This  is  the  dday  incurred  by  packets  as  they  pass  a  station's  ring  imerfru:e. 
Powers  gives  1  fxsec.  (1993,  p.336);  60.0e-08  sec.  agrees  with  Dykeman  and  Bux  (1988). 
Station  latency  is  a  component  of  D_Max  in  Equation  1 . 

L  -pmpjiday” 

Propagation  dday  is  the  time  sq>arating  stations  on  a  ring,  based  on  the 
amount  offiber  between  them.  Itis  given  here  in  seconds,  and  may  be  used  to  define  the  ring 
size.  The  INTT  state  of  process  f  dd  1  .mac  calls  this  value,  which  is  used  as  one  of  the  delay 
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parameters  applied  to  transmisston  commands.  FDDI  standards  limit  the  ring  size  to  a 
ftMvimuin  of 200  miles  of  fiber  (Dykeman,  1988,  p.  997),  and  OPNET*  assumes  that  the  fiber 
length  is  divided  evenly  among  the  stations.  That  is,  all  stations  are  evenly  ^»ced  on  the 
LAN  in  OPNET*  simulations,  wdiatever  the  cumber  of  stations  and  length  of  fiber.  Dykeman 
and  Bux  (1988,  p.  1000)  define  propagation  dday  in  units  of  time  per  distance,  and  give  a 
value  of  S.08S  /is/km.  The  value  given  in  the  original  example  environment  file,  S.08S  x  10* 
seconds,  corresponds  to  one  kilometer  of  fiber  between  stations. 
iH.  **acceleralUm_tokeH'* 

This  attribute  speeds  the  .  Nation  by  removing  the  token  during  idle 
periods  >;riien  no  station  has  packets  to  transmit,  significantly  reducing  the  number  of  events. 
iL  •^duration** 

TUs  is  the  simulated  run  time  in  seconds.  Most  systems  should  reach 
steady  state  in  less  than  a  second. 

o.  **verbosejam” 

This  feature  enables  on-screen  reports  regarding  event  numbers,  time 
remaining  until  completion,  etc. 

p,  -updjnt” 

This  specifies  in  seconds  the  intervals  at  which  to  make  on-screen 
simulation  status  updates.  It  must  be  less  than  duration  to  be  useful. 
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f.  -o$ JUe- 

The  output  scalar  file  receives  scalar  data  accumulated  over  several 
diwiiitifiiM  Itisusefiilinobaervingdieeflfectofvaiyingoiieor  more  attributes,  for  example 
TTRT,  over  a  series  of  e)q>eriments. 

r.  -ov JUe- 

The  ouqxit  vector  file  receives  throughput  and  dday  information  relevam 
to  one  simulation  rtm.  Output  vector  files  can  be  quite  large,  on  the  order  of  several 
megabits,  and  for  this  reason  are  often  automatically  deleted  by  a  <  ”c  7  eanup  ’>  command 
included  in  a  UNIX  station's  logofif  sequence.  The  user  should  alter  the  filename  or  save 
desired  (dots  as  "  .ac**  files  using  die  Analysis  Tool,  rather  than  log  off  planning  to  study  the 
vector  data  at  some  future  time. 

s.  "seerf" 

This  is  a  constant  used  by  the  ^ulation's  random  number  generator.  It 
may  be  any  positive  integer,  but  should  be  left  constant  once  chosen, 
t  ”debug- 

This  enables  the  Debug  Tool,  allowing  the  user  to  stqp  throu^  a  simulation 
one  event  at  a  time.  Once  enabled,  the  comnumd  <  ’help’>  provides  a  listing  of  the 
debugger's  features. 
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D.  SIMULATION 


This  section  presents  the  steps  involved  in  running  a  simulation  and  observing  the 
resulting  output  data.  The  user  must  keep  in  mind  that  OPNET*  is  unaware  of  IEEE  802.S. 
That  is,  it  is  the  user's  re^nsibility  to  ensure  reasonable  ii^t  parameters  are  assigned  in 
keqnng  with  the  established  standards.  The  steps  given  will  use  the  original  model  provided. 

1.  Build  the  LAN 

If  a  32-station  LAN  is  not  already  available  m  the  Network  Editor,  then  one 
should  be  created  using  the  comnuuid  <  "fddi^build.  em.  x  32’>,  as  described  earlier. 

2.  Correct  "OPBUG  2070" 

The  simulation  will  abort  if  the  original  process  model  f  dd1_s  1  nk  is  used  for  the 
SINK  node  11  c_s  1  nk,  and  some  sution  hiqrpois  to  have  not  received  any  packets.  The 
correction  described  earlier  should  be  applied,  and  the  model  recompiled  and  saved. 

3.  Implement  "OPBUG  2081"  Patch 

As  described  earlier,  this  repair  corrects  minor  tuning  inaccuracies  in  the  model, 
related  to  the  token  and  to  the  token  acceleration  feature.  The  simulation  will  work  without 
aborting  if  the  patch  is  not  applied,  but  the  user  planrung  on  implementing  code  changes 
within  the  model  over  the  long  term  should  patch  the  model  before  doing  so. 

4.  Update  Environment  File 

Refer  to  the  configuration  file  in  Appendix  C  for  irqnit  parameters.  As  mentioned 
before,  use  of  this  file  will  save  the  user  the  dfort  involved  in  setting  parameters  by  hand 
through  the  Node,  Network,  and  Simulation  Editors.  Note  that  attributes  assigned  in  the 
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EnvircMiment  file  will  supersede  any  that  are  assigned  through  these  editors.  The  fite  should 
be  given  some  distinguishing  name,  for  example  "f ddl  32 .  ef 

5.  Generate  Probe  File 

Use  ofa  Probe  file  is  optkmal.  The  process  code  as  written  will  generate  vector 
file  outputs  only  for  overall  throughput,  dday,  and  mean  delay.  Additional  outputs  may  be 
monitored  throu^  the  use  ofa  Probe  file,  illustrated  in  Figure  16.  Vol.  4.1,  Tool  Operations 
Manual,  Tb,”  describes  the  Probe  Editor.  Wttii  it  the  user  iruy  monitor,  for  exanqrle,  eadi 
station's  arrivals  (packet  generation)  and  throu^iput  at  any  physical  imerfiu«  point  on  the 
LAN,  measured  in  packets  and/or  in  bits  per  second.  For  simplicity,  only  packet  arrivals  at 
station  f  1 1  will  be  assigned  a  probe  in  this  simulation. 

6.  Simulation  Editor 

Figure  17  illustrates  the  Simulation  Tool  in  the  user  interface  window,  with  the 
settings  necessary  to  rtm  this  simulation.  Use  of  this  tool  is  discussed  in  Vol.  4.1,  Tool 
Operations  Manual,  "Sm".  Fields  are  assigned  by  use  of  the  cursor,  and  are  fiUed  by 
choosing  from  on-screen  menus  or  keyboard  entry.  The  "Slmul  at1  on”  field  should  be 
assigned  the  LAN  filename,  <  fd<ii_32^net>  (note  that  filename  suffixes  are  not  visible  to  the 
user  in  the  various  Editors).  The  fields  "Probe  File",  "Vector  File",  "Scalar  File", 
"Seed”,  "Duration”,  and  "Upd  Intvl”  truly  all  be  left  blank  if  they  are  assigned  in  the 
configuration  file;  "Probe  FI  1  e"  is  optional  in  any  case.  The  "Arg  Name”  field  should  be 
assigned  ^environment  f11e>,  and  the  "Arg  Value”  field  should  be  assigned  the 
<  f  7 1  ename>  given  to  the  environment  file.  The  user  may  then  save  the  work  area  using  the 
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Figure  16.  Probe  Assignment 
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"Urltt  Simulation"  icon,  to  spare  the  effort  of  filling  in  these  fidds  again  on  fimire 
simulations. 

7.  Start  the  Simulatioii 

Oncethefiddsareaet,thesinulationisstaited  with  the  "Execute  Simulation 
Sequence"  icon.  Had  the  user  n^ected  to  assign  some  parameter,  the  simulation  will  wait 
until  the  command  line  prompt  has  been  answered;  the  user  should  keep  the  command  screen 
in  view.  Upon  completion  of  the  simulation,  a  vector  file  (sufiBx  " .  ov")  will  be  generated, 
along  with  a  scalar  file  (suffix  ".os").  The  "Rehash"  icon  must  be  invoked  to  refi’esh 
OPNET*'s  access  to  the  files.  Then  the  user  may  exit  the  Simulation  Tool  and  enter  rhe 
Analysis  Tool. 

8.  Analysis 

Figure  18  shows  the  Analysis  tod  in  the  user  interface  window,  whose  operation 
is  explained  in  Vol.  4. 1,  Too/  Operations  Manual.  The  first  action  upon  entering  this  tool  is 
to  call  the  available  vector  outputs,  uang  the  "Open  Output  Vector  File"  icon,  then 
sdecting  from  the  choices  presented.  If  more  than  one  are  present,  choose  the  one  that  was 
assigned  in  the  environment  file.  The  on-screen  menu  will  then  disappear,  leaving  the  user 
to  select  the  "Create  SI  ngl  e  Vector  Panel "  icon,  which  presents  the  on-screen  menu 
shown  in  Figure  18.  The  entries  "end-to-end  delay  (sec.)",  "throughput 
(bits/sec)",  and  "mean  delay  (sec. )"  are  generated  directly  firom  the  SINK  process 
modd.  The  remaining  fidd,  "r1ng0.fll.mac[0].plcs1ze."  comes  fi’om  the  Probe  Editor. 
Each  may  be  plotted  by  sdection  with  the  cursor,  then  dragging  the  box  comers  to  the  desired 
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Figure  18.  Vector  Trace  Selection  in  the  Analysis  Tool 
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size.  Having  placed  the  panel,  the  plotted  points  are  fired  by  clicking  the  left  mouse  button, 
or  by  placing  the  cursor  over  the  "FI  re  A1 1  Panel  s"  icon  and  clicking  the  same  button. 
Figure  19  shows  all  four  plots  generated,  placed  together  on  the  screen.  The  "Create 
Mul  t1  -  Vector  Panel "  icon  is  used  to  place  several  plots  in  the  same  panel,  an  operation  that 
is  meaningful  when  the  Probe  Editor  is  used  to  generate  comparable  outputs.  Once  the 
desired  plots  are  on  the  screen,  they  may  be  saved  with  the  "Write  Analysis 
Conf  1  guratl  on"  icon,  which  will  store  the  plots  in  a  " .  ac"  file  for  later  recovery.  This  is 
important  because  the  vector  file  will  be  written  over  the  next  time  a  simulation  is  run  using 
the  same  output  vector  filename.  In  addition,  the  UNIX  station's  logout  sequence  may 
include  a  <  'remove  *.  ov'>  command  to  prevent  the  accumulation  of  large  vector  files  in 
memory. 

The  output  scalar  file,  on  the  other  hand,  accumulates  steady-state  data  over 
several  simulations,  allowing  the  generation  of  plots  showing,  for  example,  the  effect  of 
various  TTRT  values  on  total  throughput.  The  user  wishing  to  create  su  :i  plot  should 
ensure  the  file  is  empty  of  previous  data  before  commencing  a  series  of  simulations. 

9.  Debug  Tool 

The  debug  tool  may  be  activated  fi'om  the  environment  file.  The  command 
<'help  *>  will  list  the  available  commands.  Tl«  user  may  step  through  a  simulation  one  event 
at  a  time,  or  specify  stopping  points.  The  <'fulltrace'>  command  causes  every  variable 
to  be  reported  at  each  event,  allowing  the  user  to  follow  the  sequence  of  events  in  a 
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«itiriiii«tiAn,  ayiH  to  soardi  for  logK  eiTors  should  foilures  occur.  Appendix  D  is  a  short  section 
of  the  drugget's  output  when  the  <  '  fu  ?  7 1  race  *>  command  is  active. 
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in.  MODEL  MODIFICATIONS 


A.  OVERVIEW 

The  FDDI  station  model  provided  with  OPNET*  is  shown  by  Schenone  (1993)  to 
perfi»in  as  e9q)ected  by  performance  equations  provided  by  research  literature,  for  example, 
Dykeman  and  Bux  (1988).  However,  the  modd  as  given  lacks  the  flexibility  to  adequatdy 
demonstrate  the  characteristics  and  metrics  required  to  formulate  recommendations  for  the 
devdopment  of  a  CDL  network  interfice.  To  be^  no  way  exists  in  the  ori^nal  model  to 
monitor  the  throughput  and  dday  statistics  of  synchronous  trafBc  separatdy  from 
asynchronous  trafSc.  In  addition,  the  code  must  be  modified  to  allow  the  implementation  of 
different  asynchronous  priority  levds,  and  further  altered  to  allow  the  generation  of  statistics 
of  these  subcategories.  Also  desirable  is  a  method  to  hold  trafBc  in  the  sink  process  of  one 
station  on  the  LAN,  rather  than  destroying  all  packets,  so  that  a  bridging  protocol  may 
eventually  be  devdoped  for  communication  between  LANs,  which  is  the  ultimate  goal  of  the 
Common  Data  Link  Project.  Fiiudly,  a  multicast/broadcast  facility,  by  which  a  packet  may 
be  addressed  to  multiple  stations,  is  needed.  Modifications  implementing  these  features  were 
generated  for  this  thesis,  and  are  described  in  this  chapter.  Appendices  E,  F,  and  G  contain 
the  final  form  of  the  "C"  programs  representing  the  process  models  "fddl.mac.mult", 
"fdd1_gen_mulf,  and  "fdd1_s1nk_mult",  respectively.  All  contain  inserted  comments 
to  indicate  where  changes  have  been  made.  In  some  cases,  modifications  are  extensive 
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enough  that  the  original  structure  is  not  apparent.  For  these  cases  the  reader  \idio  is 
interested  in  conqjarisons  is  referred  to  the  original  code  available  in  the  Process  Editor. 

The  modifications  desoibed  here  were  suggested  in  large  part  fi-om  readings  in  the 
research  literature.  In  particular,  Tari,  Schaffer,  Poon  and  Nfick  (1991)  published  results 
generated  fiom  arwther  commercially  produced  network  simulation  tool,  the  Block  Oriented 
Network  Simulator  (BONeS*),  demonstrating  that  increased  asynchronous  offered  traffic 
load  has  minimal  effect  on  the  througl^ut  of  synchronous  voice  data  traffic.  At  the  same 
time,  the  throughput  of  the  various  asynchronous  levds  was  shown  to  degrade  in  order  of 
priority  with  increasing  asynchronous  offered  load.  These  findings  emphasize  the  &ct  that 
OPNET*  has  no  facility  in  place  providing  for  the  monitoring  and  plotting  of  throughput  or 
delay  data  in  respect  to  class  or  priority  levels. 

Closely  interrelated  are  file  setting  of  asynchronous  priority  levels,  a  system  of 
subqueues  to  segregate  traffic  by  priority,  and  the  gathering  and  display  of  performance 
statistics  according  to  priority.  In  the  following  discussion,  reference  is  sometimes  made  from 
one  to  the  others  before  all  are  complete. 

B.  PRIORITIZATION 

1.  Activating  Prioritization  in  OPNEl^s  FDDI  Model 

As  given  in  the  original  released  model,  code  exists  to  support  a  prioritization 
scheme,  but  it  is  not  implemented.  The  station  model  includes  a  priority  field  that  may  be  set 
in  the  Node  Editor,  but  no  setting  will  take  effect  until  the  INTT  state  in  the  MAC  process  is 
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modified.  As  given,  T_Prl  [1  ]  is  simply  assigned  the  value  <Fddl_T_Opr>  (which  is  the 
nfgoriatarf  value  of  TTRT,  with  the  m^t^iation  consistaig  of  sdection  of  the  lowest  requested 
T.Req  from  all  stations)  for  all  priority  settings  i ,  resulting  in  no  distinction  made  between 
priorities.  The  state  TX.OATA  in  the  MAC  process  modd  contains  the  code  that  determines 
transmission  eligibility,  then  transmits  packets  if  timing  conditions  are  satisfied.  The  user 
should  notice  here  that  unlike  the  real  FDDI  protocol,  the  Token  Holding  Timer  is 
incremented  fiom  zero  to  tht.val  ue  (IKT),  not  decremented  fix>m  THT  to  zero.  This 
results  in  a  reorientation  of  T.PriCi]  settings,  wherein  higher  settings  allow  a  largo' 
transmission  window,  and  thoefore,  higho  priority.  To  re-emphasize,  in  the  OPNET* 
model,  T.Pri  [1  ]  is  largo  for  higho  priority  stations.  Actual  settings  of  T_Pri  [i  ]  are  a 
matto  of  user's  choice  and  real-world  physical  characteristics.  One  quick  approach  is  to  alto 
the  code  m  INIT  from  the  original; 

for  (i  “  0;  1  <8;  1++) 

1 

T_Pri  [1]  -  Fdd1_T_0pr; 

) 

by  substituting  the  text. 

T_Pri  [i]  -  (doub1e)Fddi_T_0pr/ (8- i ) : 

to  impart  some  weight  to  the  priority  settings  (Appendix  E,  line  250).  Note  that  priority 
settings  in  OPNET*  are  counted  from  zoo  to  seven,  in  keeping  with  the  "C  programming 
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language  convention  of  numbering  dements  of  an  N-dement  array  from  zero  to  N-1 .  As 
mentioned  earlier,  actual  FDDI  convention  numbers  the  priority  settings  from  one  to  dght. 

2.  Changing  the  Scheme  and  the  Code 

For  the  purposes  of  CDL,  an  ability  in  a  station  to  generate  tra£5c  of  differing 
priorities  is  a  desirable  characteristic.  The  modifications  discussed  here  allow  this  behavior, 
thou^  with  a  certain  amount  of  abstraction  included.  Essentially,  each  packet  generated  in 
the  source  process  is  assigned  a  pri<mty  setting,  in  a  manner  that  is  fiinctionally  identical  to 
the  determination  of  the  destination  address.  However,  the  priority  of  one  packet  has  no 
influence  on  the  priority  of  the  next  one  generated  at  the  same  station.  Of  course  in 
real-world  transmisdons,  packets  are  grouped  imo  messages,  meaning  that  thousands  of 
consecutive  packet  arrivals  should  have  the  same  priority  settings  to  reflect  real  behavior.  In 
fact,  the  subqueue  structure  imparted  to  the  MAC  causes  outgoing  packets  to  be  sent  in 
decreasing  order  of  priority,  thereby  modding  expected  bdiavior  to  some  small  degree.  More 
significantly,  the  user  should  keep  in  mind  that  the  model's  purpose  is  to  model  a  LAN's 
handling  of  the  traffic  it  does  receive.  The  fiun  that  packets  are  transmitted  with  random 
priorities  in  a  scattershot  frshion  is  not  significant  to  the  LAN’s  overall  performance. 

3.  Subqueues 

Because  subqueues  are  essential  to  the  devdopment  of  the  prioritization  scheme, 
thdr  construction  is  addressed  first.  As  is  seen  in  the  FDDI  station  model  in  the  Node  Editor, 
the  MAC  node  is  represented  as  a  queue.  Therefore,  only  a  change  to  "subqueue  count” 
field  in  the  attributes  menu  is  necessary  to  change  the  MAC'S  structure  into  a  bank  of 
subqueues.  Code  is  already  in  place  that  treats  the  MAC  as  a  set  of  subqueues,  although  by 
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default,  only  one  is  available  at  first  (this  is  labelled  <subqueue  (0)>,  as  is  seen  when  the 
"subqueues"  field  is  selected  fi-om  the  on-screen  attributes  menu  for  the  MAC  node.  Nine 
subqueues  are  desired  here;  one  for  each  asynchronous  priority  setting,  plus  another  to  handle 
synchronous  trafiSc.  Subqueue  indexing  corresponds  to  priority  settings,  so  that  subqueue 
(0)  receives  and  rdeases  the  lowest  priority  asynchronous  traffic,  while  subqueue  (7)  is 
assigned  the  highest  priority  traffic.  Subqueue  (8)  is  designated  for  synchronous  traffic.  This 
segregation  of  traffic  into  subqueues  is  necessary  to  support  the  recording  of  performance 
statistics  and  plots  of  traffic  generation  throu^  the  use  of  the  Probe  Editor.  Also,  while  the 
Kernel  Procedures  (KP)  available  to  the  user  include  one  that  aUows  packets  to  be  removed 
from  the  transmission  queue  in  order  of  priority,  rather  than  in  the  usual  first-in-first-out 
(FIFO)  order,  subqueues  allow  simpler  logic  (Vols.  S.O  and  5.1  are  directories  of  the 
commands  and  fimctions  used  by  OPNET^.  Vol.  2.0,  Modeling  Manual,  "Ndde^ "  pp. 
27-29,  describes  the  procedure  to  adjust  code  so  that  references  to  queues  may  be  replaced 
with  references  to  subqueues,  particularly  in  relation  to  prioritization  schemes.  In  summary, 
the  subqueues  represent  a  way  point  for  packets.  They  are  created  and  assigned  a  priority 
setting  in  the  source,  encapsulated  for  transmission  in  the  MAC  (ENCAP  state),  and  placed 
in  the  appropriate  subqueue  while  the  station  awaits  the  next  token  arrival  to  transmit  them. 
a.  •’RCVJTK" 

In  the  RCV_TK  (receive  token)  state,  the  first  test  of  token  usability  is  a 
determination  of  the  presence  of  outbound  traffic.  The  statement; 

1f  (op_q_stat  (OPC^QSTAT.PKSIZE)  >0.0) 

. . .  etc  . . . 
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calls  for  an  inspection  of  the  queue.  This  statement  is  replaced  with  a  loop  structure  that 
searches  aU  subqueues; 


for  (1  -  NUM.PRIOS  -  1:  1  >  -1;  1--) 

{ 

1f  (op_subq_stat  (1.  OPC_QSTAT_PKSIZE)  >  0.0) 


(Appendix  E,  line  453) 

Of  course  the  above  require  a  declaration  of  the  variable  NUM.PRI  OS  and 
the  loop  counter  1 . 

b.  -TX_DATA- 

The  TX_DATA  (transmit  data)  state  contains  the  code  that  transmits 
packets  while  the  token  remains  available,  and  monitors  THT.  The  THT  (tht.val  ue)  is 
checked  inside  a  loop  \s^se  condition  is,  "saddle  packets  remain  in  the  queue,  transmit."  This 
loop  contains  most  of  the  code  in  TX_DATA.  This  condition  must  be  set  inside  another  loop 
>aiiich  counts  through  each  desired  subqueue,  and  which  must  include  an  additional  number 
of  "break  loop"  poims.  Accordingly,  the  code; 


while  {op_q_stat  (OPC  QSTAT_PKSIZE)  >  0.0) 

I 

/*  Remove  the  next  frame  for  transmission.*/ 
pkptr  -  op_subq_pk_remove  (0,0PC_QP0S_HEAD) : 


is  rendered  into  the  following; 


for  (1  -  NUM  PRIOS  -  1:  1  >  -1;  i--) 

{ 

while  (op_subq_stat  (1.  OPC  QSTAT  PKSI2E)  >  0.0) 

{ 

/*  Remove  the  next  frame  for  *  ansmission.*/ 
pkptr  -  op_subq_pk_remove  (0 .0PC_QP0S_HEA0) : 

. . .  etc  . . . 

} 

} 

(Appendix  E,  line  920) 


The  transmission  loop  is  broken  vidwn  any  of  the  following  occur: 

*  No  more  packets  are  enqueued. 

»  In  the  case  of  synchronous  transmission,  insuffidem  bandwidth 
remains  to  complete  a  transmission.  (Note  that  synchronous  traffic 
is  allocated  by  the  user  an  inviolate  amount  of  time  in  which  to 
transmit,  regardless  of  the  lateness  of  the  token  However,  the 
model  checks  the  bandwidti^  emaining  to  ensure  a  transmission  can 
be  comfrieted  within  the  allotted  time,  and  will  not  commence  a 
transmission  that  would  dday  the  token.  This  is  in  agreemem  with 
the  actual  protocol,  and  in  contrast  to  the  asynchronous  case,  in 
which  packet  transmission  may  commence  while  the  THT  is  active, 
even  if  the  transmisdon  will  keep  the  token  past  THT  expiration.) 

»  The  remaining  packets  are  of  too  low  a  priority  to  be  transmitted  in 
the  time  remaining  to  THT  (T_Pri[l]  <  THT). 

After  closure  of  the  outer  loop,  the  station  deregisters  its  interest  in  the 
token  by  indicating  it  has  no  more  traffic  to  send.  This  information  is  used  by  the  token 
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accderation  roechamsm,  which  destroy  the  token  fiv  the  time  period  no  station  has  traffic 
to  transmit,  then  recreate  it  v/bcn  needed,  therc^  significantly  reducing  the  number  of  events 
and  the  amount  of  time  spent  in  a  simulation.  The  ori^nal  code  appears  at  the  bottom  of  the 
TX_DATA  state; 


if  (tk_  -qistered  &&  op_q_stat  (OPC_QSTAT_PKSIZE)  —  0.0) 
{ 

tk_  ■ gi stered  -  0: 
fddi_tk_deregister  {): 

) 


As  before,  this  must  be  altered  to  search  through  a  set  of  subqueues  first 
before  deciding  no  tra£Sc  remains  to  be  sent: 


q_check  «  1 : 

for  (i  -  NUM.PRIOS  •  1;  i  <  -1;  1--) 

{ 

if  (op_subq_stat  (i.  OPC.QSTAT.PKSIZE)  —  0.0) 
{ 

q_check  -  0: 

1 

else 

{ 

q_check  ■  1; 
break: 


if  (tk_regi stered  &&  q_check  “  0) 

{ 

tk_regi stered  -  0: 
fddi_tk_deregister  (); 

) 

(Appendix  E,  line  1084) 
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4.  Modifications  to  Prioritizntion 

In  order  to  enact  the  priority  scheme  described  above,  changes  are  needed  in  the 
station  model  (Node  Editor),  all  three  process  modds  (Process  Editor),  packet  format 
(Parameto’  Editor),  and  to  the  Environment  file  (UNIX  text  editor). 
a.  Station  Modd  Changes 

For  the  modified  priority  scheme,  new  attributes  are  needed  in  the 
on-screen  menus  that  appear  for  the  mac  node  of  the  fdd1_statl  on  modd  in  the  Node 
Editor.  The  original  fidd  "pri  orl  ty"  is  in  place,  but  not  used.  Note  that  the  "super 
priority"  fidd  (described  in  Vol.  6.0,  External Imerfaces Manuai,  "Rd,"  p.  IS)  is  not 
related  to  the  FDDI  protocol,  but  is  a  tool  for  scheduling  of  events  in  the  simulation;  it  is  not 
used,  and  should  be  left  disabled. 

In  order  to  support  the  priority  setting  protocol  that  occurs  in  the  source 
model  (described  later),  two  new  attributes  are  created;  "high  pkt  priority"  and  "low  pkt 
priority."  The  new  fields  are  created  as  listed  in  the  following  steps; 

1 .  Call  the  on-screen  attributes  menu  for  the  "mac"  node. 

2.  Place  the  cursor  over  the  "extended  attrs"  field,  and  press  the  left  mouse 
button  to  call  the  submenu  (the  ri^t  mouse  button  dismisses  the  attributes  menu; 
try  again). 

3.  Assign  the  fidds  as  shown  in  Figure  20;  names  will  be  "low  pkt  priority" 
and  "high  pkt  pr1or1ty",unitsare<none>,  type  is  <7nteger>  (selected  fi-om 
another  on-screen  menu  that  will  appear. 
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Figure  20.  Adding  Extended  Attributes  to  the  Station  Model 


rather  than  typed  in),  and  defaults  are  at  the  user's  discretion.  Zero  for  both  are 
reasonable.  These  assignments  are  preserved  with  the  keyboard  combination 
<CTRL+S>.  Further,  the  model  must  be  saved  using  the  "Write  Node  Model” 
icon,  as  described  in  Vol.  4.0,  Tool  Operations  Manual,  "Nd,"  pp.13-15. 

4.  Once  the  modd  is  saved,  then  called  again  to  the  Node  Editor,  unexpected  values 
will  probably  i^jpear  in  the  fidds  corresponding  to  the  new  attributes  (which  will 
now  appear  in  the  primary  on-screen  menu  as  well  as  in  the  "extended  attrs" 
submenu).  These  values  should  be  set  to  <proinotecl>  so  that  they  may  be 
assigned  in  the  Environment  file.  To  set  the  newly  created  field  to  <promotsd>, 
place  the  cursor  over  the  fidd,  then  type  <CHTL*0'>  at  the  keyboard,  invoking  the 
literal  "promoted." 

This  last  hem  is  not  desaibed  in  the  manuals;  it  was  obtained  fi^om  MIL  3, 
Inc.'s  technical  support  via  electronic  mail. 

b.  Environment  File  Changes 

Corresponding  to  the  attributes  created  and  then  assigned  <promoted> 
fields  above,  the  following  code  is  added  to  the  Environment  file; 

■*.*.nc_src.high  pkt  priority"  :  7 
1 lc_src. low  pkt  priority"  :  0 

The  quotation  marks  are  required  here  because  of  the  spaces  in  the  attribute  names.  Had 
1  ow_pkt_pr  i  or  i  ty  been  used  instead,  then  the  quotation  marks  would  have  been  onutted. 
Examples  of  both  styles  appear  in  Appendix  H,  an  example  Environment  file  that  includes  all 


60 


attributes  added  to  the  modd  (some  of  v^ch  are  stiU  to  be  described).  The  Environment  file 
may  be  modified  in  the  UNIX  text  editor.  Pound  signs  (#)  indicate  comments.  Order  of 
attributes  is  not  significant,  and  any  attributes  not  used  by  a  model  are  simply  ignored. 
c.  Source  ModificadoHS 

The  approach  to  assigning  a  random  priority  to  each  packet  as  its  arrival 
is  generated  is  fimctionally  identical  to  the  procedure  by  which  the  destination  address  is 
generated.  The  OPNET*  kernel  fimetion  op_1ma_obJ_attr_get( )  is  used  to  call  attributes 
from  the  node  modd  or  fiom  the  Environment  file.  The  KP  op_d  1  s  t_l  oa  d  ( )  is  used  to  load 
a  distribution  to  be  used  in  generating  a  stream  of  stochastic  values.  These  are  used  in  the 
source  process  modd  "fddl.gen"  INTT  state  in  the  following  maimer; 

op_inia_attr_get(my_id. ’high  pkt  priority, 
ih1 gh_pkt_pri ori ty ) : 

op_1ma_attr_get(my_1d. ’low  pkt  priority" 

&low_pkt_prior1ty) : 

pkt_priority_ptr  -  op^dist.load  (•uniform_int’ , 
1ow_pkt_prior1ty ,  &high_pkt_priority) : 

(Appendix  F,  line  108) 

In  the  preceding,  the  first  two  lines  call  the  desired  attributes  firom  the 
Environment  file  to  the  calling  station  ("my_i  d").  The  second  field  in  the  procedure  call  is 
taken  verbatim  fi-om  the  Environment  file,  while  the  third  field  is  the  address  of  the  attribute. 
The  address  may  have  any  name;  <Shigh_pkt_priori ty>  is  purely  a  memory  aid  for  the 
user,  and  is  not  required  by  syntax  to  resemble  the  field  name  to  which  it  is  assigned.  The 
value  returned  by  op_d1  st_i  oad  ( )  is  used  in  the  ARRIVAL  state  to  finally  generate  the 
priority  setting  with  the  statement; 
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pkt_pr1o  -  op_d1st_outcome  (pkt_prior1 ty_ptr ) ; 

(Appendix  F,  line  195) 

which  finaUy  returns  an  integer  between  the  values  set  in  the  Environment  file.  This  integer 
is  assigned  to  the  packet  with  the  commands; 

op_pk_nfd_set  (pkptr.  "prl",  pkt_pr1o); 

op_1c1_attr_set  (mac_1c1ptr,  "prl*.  pkt_prio): 

(Appendix  F,  line  214) 

Where  only  one  priority  setting  is  desired  for  a  particular  station,  the 
attributes  need  only  be  both  set  to  that  d^ed  value,  with  the  station  specified  in  the 
Environment  file.  A  limitation  here  is  simihu  to  that  of  addressing:  any  section  of  values 
fi-om  zero  to  seven  may  be  chosen,  but  it  is  not  possible,  for  example,  to  assign  a  station  the 
asynchronous  priority  settings  two,  four,  and  six. 

In  the  SV  (State  Variable)  edit  window,  high.pkt_prlorlty  and 
1  ow_pkt_prl  orl  ty  are  declared  as  im^ers,  and  pkt_pri  ori  ty.ptr  is  declared  as  a  pointer 
of  type  "Distribution."  BecauM  OPNET*  uses  a  form  of  proto-C,  the  declarations  made  in 
the  editor  actually  have  the  following  form; 
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Distribution*  \pkt_pr1or1ty_ptr: 
Int  \h1gh_pkt_pr1or1ty : 

1nt  \low_pkt_pr1or1ty : 


(Appendix  F,  line  9) 

When  the  code  is  compiled  and  the  "  C"  icon  is  invoked  to  present  the 
entire  process  model  code,  the  above  will  have  the  following  appearance; 


D1  stn  buti  on*  s v_pkt_pr1or1  ty_ptr ; 
int  sv_high_pkt_pr1or1ty : 

int  sv_low_pkt_pr1or1 ty : 


OPNET*  will  also  produce  the  following  in  the  ".C  code; 


^define  pkt_prior1ty_ptr 

p  r_s  t a  t e_pt  r • >  s  v_pkt_p  r i o  r i ty_pt  r 
^define  blgb_pkt_priority 

pr_state_ptr->sv_high_pkt_priority 
#def1ne  lov.pkt^priority 

pr_state_ptr*>sv_l ow_pkt_pr1orl ty 


(Appendbc  F,  line  44) 

The  above  commands  have  the  effect  of  choosing,  on  a  uniform 
distribution,  a  priority  setting  from  a  given  range  whose  endpoints  are  retrieved  from  the 
Environment  file. 

d.  MAC  Modificatio  ns 

Because  a  priority  scheme  is  already  supported  in  the  original  model,  little 
change  is  required  in  the  ma  c  node  once  a  prionty  value  is  assigned  in  the  source  node.  The 
user  should  note  that  communication  between  nodes  is  conducted  with  locally  held  variables; 
globals  are  avoided.  This  may  result  in  different  declared  variable  names  for  the  same  data. 
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which  is  accqnable.  Thus,  the  pri  of  the  source  becomes  the  req.pri  of  the  mac  node.  In 
the  MAC  node,  priority  settings  are  used  as  the  indexes  for  the  subqueues.  NUH.PRIOS  is 
declared  for  use  as  a  loop  counter. 


e.  Sink  Node  ModificatioHS 

The  changes  to  the  "fddl.slnk”  process  are  nearly  all  rdated  to  the 
generation  of  performance  parameters,  which  are  discussed  in  the  next  section.  In  the  origiiud 
model,  the  received  packet's  priority  setting  is  not  even  relayed  to  the  sink,  since  the  only 
information  necessary  to  the  calculation  of  overall  througlq>ut  and  delay  statistics  are  the 
packet's  creation  time  and  its  time  of  receipt.  A  fundamental  addition  to  the  code  in  the 
DISCARD  state  is  the  line; 

op_pk_nfd_get  (pkptr,  *prl*,  4pr1_set): 

(Appendix  F,  line  78) 

which  recovers  the  priority  from  the  field  "pri"  in  the  fiwne  structure  fddi_l  1  c_f  r.  With 
this  information,  additional  modifications  will  bring  about  the  ability  to  create  throughput  and 
delay  information  for  each  asynchronous  priority  setting,  and  also  to  separate  synchronous 
traffic  statistics  from  asynchronous.  Bui  before  any  of  this  will  work,  the  fddl.l  l  c_f  r 
packet  structure  must  be  modified. 

/  Packet  Format 

The  frame  that  is  created  in  the  source  and  passed  to  the  MAC,  then 
enciq>sulated  into  a  more  extensive  finme,  then  ultimately  passed  from  the  destination  station's 
MAC  to  the  sink  process  for  accounting  and  final  destruction,  is  of  the  format  f  ddl_l  1  c_f  r. 
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To  support  the  prioiitizatitm  scheme,  the  format  needs  to  include  more  information  than  only 
the  frame's  creation  time.  To  enhance  its  characteristics,  the  Parameter  Editor's  "Packet 
Format"  icon  is  invoked,  and  the  format  fddi_l  l  c_f  r  is  called.  Another  line  is  added,  as 
shown  in  Figure  21,  making  "priority"  an  attribute  of  the  packet.  Type  is  set  to 
"1  nteger . "  size  can  be  "0,"  definik  value  is  "0,"  and  default  set  is  "unset."  The  changes  are 
saved  with  the  "Uri  te  Model "  icon. 

C.  PERFORMANCE  MEASURES 

1.  Overview 

OPNEl^s  original  FDDI  LAN  model  provides  no  ready  way  to  monitor 
synchronous  traffic  sqwatd^  fiom  asynchronous,  and  no  way  to  monitor  the  throughput  and 
delay  statistics  for  individual  asynchronous  levels.  The  inability  of  OPNEI^s  original  FDDI 
model  to  provide  anything  besides  overall  poformance  is  a  serious  limitation  to  its  usefulness 
in  the  Q3L  project.  A  nuyor  goal  of  this  work  is  to  augment  the  code  in  the  sink  process  so 
that  additional  output  vectors  are  generated,  allowing  the  effects  on  individual  class  and 
priority  levels  to  be  seen.  For  example,  in  the  original  model,  the  user  may  assign  any  desired 
proportion  of  the  generated  traffic  to  be  synchronous,  but  the  original  model  has  no  facility 
to  measure  the  synchronous  traffic  alone.  The  following  paragraphs  describe  the 
modifications  made  to  allow  the  display  of  statistics  segregated  by  class  and  priority. 

As  an  incidental  note,  the  user  should  realize  there  is  no  particular  significance 
to  the  sequence  in  which  the  states  appear  in  the  ".C"  file.  That  is,  the  order  DISCARD, 
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Figure  21.  Adding  a  New  Field  to  the  ’’fddi_Uc_fr"  Frame  Format 
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STATS,  then  INTT  that  q)pears  in  the  "fddl.sl  nk”  process  code  is  no  indication  of  the 
sequence  in  which  the  simulation  "visits''  these  states  for  each  station.  In  fiict,  the  more 
logical  order,  INTT,  DISCARD,  then  STATS  will  be  followed  in  this  discussion,  though 
preceded  by  a  discussion  of  the  variables  needed.  Appendix  G  is  the  file 
"f  dd1_s  1  nk_mu1 1 .  pr .  c",  containing  the  modifications  described  here. 

2.  Variables 

There  are  essennaOy  fbar  primary  >auiables  of  interest  in  the  sink  process  model; 
fddi_sink_accum_delay,  fdd1_s1nk_total_pkts,  fdd1_s1nk_tota1_bits,  and 
fdd1_s1nk_peak.delay.  These  exist  as  sin^e  int^ers  or  as  floating  point  numbers,  and  are 
incremented  or  recomputed  as  packets  are  recdved  by  the  station.  The  overall  idea  is  to 
expand  these  into  vector  arrays,  in  which  each  element  represents  a  iimning  total  for  one 
priority  setting,  with  the  last  element  represoiting  synchronous  trafiSc  totals.  As  mentioned 
earlier,  this  approach  requires  the  "fddl.mac.fr”  format  in  the  Parameter  Editor  to  be 
modified  to  include  the  priority  as  a  field,  since  the  original  model  needs  only  the  packets' 
creation  time  and  time  of  arrival  in  order  to  compute  the  overall  throughput,  mean  delay,  and 
end-to-end  delay.  However,  as  was  discovered  through  trial  and  error,  while  the  given 
variables  can  be  changed  to  vector  arrays,  and  the  model  can  be  modified  to  accommodate 
the  new  structure,  and  the  code  will  compile  (if  the  syntax  is  correct),  any  attempted 
simulation  will  abort  with  a  segmentation  violation  error.  This  is  because  the  "C"  programs, 
A\^ch  may  be  modified  by  the  user,  must  inter&ce  with  OPNEI^s  kernel  procedures,  which 
are  beyond  the  user's  access.  Ultimately,  the  given  variables  must  be  kept  and  new  ones 
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created.  Since  the  overaQ  performance  remains  a  useful  statistic,  the  variables  mentioned  are 
left  in  place,  while  new  ones  are  declared  with  the  desired  vector  structure.  Th^  are 
fdd1_s1nk_accura_de1ay_a,  fdd1_s1nl(_total_pkts_a,  fdd1_s1nk_total_b1ts_a,  and 
fddi_sl  nk_peak_del  ay_a,  which  are  declared  and  iiutialized  in  the  Header  Block. 

The  following  declarations  are  added  to  the  State  Variables  section: 


Gshandle  \thru_gshandle_a[10] : 
Gshandle  \m_delay_gshandle_a[10] : 
Gshandle  \ete_delay_gshandle_aC9] : 


Once  compiled,  the  following  appear  in  the  *.€"  file; 


Gshandle  sv_thru_gshandle_a[10] : 

Gshandle  sv_ni_delay_gshandle_a[10] ; 

Gshandle  sv_ete_delay_gshandle_a[9] ; 

#def1ne  thru_gshandle_a  pr_state_ptr->sv_thru_gshandle_a 
^define  m_delay_gshandle_a 

pr_state_ptr->sv_m_delay_gshandle_a 
#def1ne  ete_del ay_gshandle_a  pr_state_ptr- 
>sv_ete_del ay_gshandle_a 


(Appendix  G,  line  43) 

With  these  declarations  in  place,  the  modifications  to  the  rest  of  the  code  are 
straightforward,  and  generally  follow  the  examples  set  by  the  original  code.  In  addition,  the 
variables  Offered.Load  and  Asynch_Offered_Load  are  declared  for  use  in  generating  scalar 
plots  over  a  series  of  simulations.  These  are  assigned  values  called  firom  the  Environment  file 
by  the  state  STATS. 
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3.  Initializatioii  State 


The  primary  purpose  of  the  Initialization  State  is  to  assign  handles  to  the  global 
statistics  that  are  generated  at  the  end  of  the  simulation.  The  "KP"  statement 
op_stat_global_reg  (<gstat_naine>)  returns  a  handle  used  to  refovnce  a  globally 
accessible  statistic.  This  handle  is  needed  to  furnish  new  values  (as  they  arrive  with  iww 
packets)  for  the  "KP"  op_stat_g1  obal.wri  te( ),  which  appears  in  the  DISCARD  state.  The 
field  entry  <  gs  ta  t_name>  is  the  text  in  the  on-screen  menu  that  appears  in  the  Aiudysis  Tool 
when  the  Create  Single  Vector  Panel  or  "Create  Multi  Vector  Panel"  icons  are 
invoked.  The  code  added  is  very  similar  to  what  is  already  in  place.  For  example: 


thru_gshandle_a[0]  -  op_stat_gl obal_reg  Cpri  1  thruput 
(bps)'): 


(Appendix  G,  line  325) 


creates  a  handle  for  the  collection  of  data  for  priority  1  level  throughput,  and  creates  a  field 
which  will  appear  in  the  on-screen  menu  in  the  Analysis  Tool.  In  another  example; 


ni_delay_g5nan<ile_a[9]  -  op_stat_global_reg  Casync  mean 
delay  (sec)*); 


(Appendix  G,  line  364) 


creates  a  handle  for  total  asynchronous  mean  delay,  and  generates  another  field  which  will 
appear  in  the  on-screen  menu  in  the  Analysis  Tool.  Each  priority  level  has  its  corresponding 
handle  assignment  line.  The  actual  statistics  to  accompany  these  handles  are  generated  in  the 
DISCARD  state.  As  seen  in  the  code  itself  (Appendix  G),  each  element  has  a  handle 
assignment  line,  for  throughput,  mean  delay,  and  end-  to-end  delay.  Figure  22  shows  off  the 
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resulting  on-screen  menu  from  the  "Create  Single  Vector  Panel "  icon,  reflecting  the 
new  data  that  may  be  plotted.  Note  that  the  code  here  reconciles  "C  language  vector 
numbering  conventions  with  real-world  priority  level  settings. 

4.  "DISCARD"  State 

The  DISCARD  state  is  where  the  received  packet  is  "opened"  and  statistics 
generated  from  the  packet  contents.  As  mentioned  before,  "KP"  op_stat_g1  oba1_wri  te 
(<g5tat_handle> .  <  va  7  ue>)  is  the  statement  that  accumulates  data.  The  <k^a7ue>  Add 
may  be  a  previously  computed  figure,  or  may  be  calculated  within  the  ”KP".  The 
<  gstat_hand  1  e>  Add  is  the  same  used  in  the  INTT  state.  DISCARD  uses  the  priority  value 
found  with  the  arriving  packet  as  the  index  for  the  vector  structure.  For  example; 

op_stat_global_wr1te  (thru_gshandle_a[5] . 
fd(l1_s1nk_tota^_b1ts_aC5]  /  op_s1ni_t1me( ) ) : 

(Appendix  G,  line  128) 

generates  a  current  througlqxit  figure  fisr  asynchronous  priority  levd  sbc  (recall  the  necessary 
offset  for  vector  element  numbering  convention)  Also  necessary  is  the  recording  of  dday 
values  for  each  priority,  which  is  done  with  the  foUowing  ; 


op_stat_global_wrlte  (ete_del ay_gshandle_a[pri_set] , 
delay) ; 


(Appendix  G.  line  182) 


This  state  also  destroys  the  packet  once  its  contents  are  recorded.  This  is  necessary  to 
prevent  the  simulation  from  filling  the  host  computer's  memory  with  dead  packets. 
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Figure  22.  Newly  Created  Vector  Traces  Available 


5. 


"STATS"  SUte 


The  STATS  state  produces  the  steady-state  scalar  data  that  may  plotted  using  the 
"Create  Seal  a  r  Panel "  icon.  These  are  saved,  rather  than  written  over,  so  that  the  user 
may  observe  changes  to  output  as  the  input  is  varied.  For  example,  the  throughput  of 
qmchronous  traffic  over  several  simulations  as  different  TTRT  values  are  used.  From  these, 
a  plot  of  throughput  vs.  TTRT  may  be  generated.  The  statement  . 

op_stat_scalar_wr1te  (.<scstat_name> ,  <value>): 

is  similar  to  the  "wr1  te"  command  described  before,  and  writes  a  scalar  steady-state  statistic 
in  this  case.  The  field  "scstat"  appears  in  the  on-screen  menu  called  with  the  "Create 
Seal  ar  Panel"  icon.  Examples  of  the  use  of  this  statement  appear  in  Appendix  G,  lines 
210-226. 

Another  on-screen  menu  line  item  is  drawn  fi'om  the  Environment  file.  The 
values  <tota  l_offered_load>  and  <asynch_offered^load>  are  placed  and  assigned  in 
the  Environment  file  (see  Appendix  H),  as  described  earlier.  These  correspond  to  the 
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1 


vtfiaUes  Asynch_Offered_Load  snd  Offered.Load  declared  in  the  header  block.  These  are 
joined  by  the  commands; 


op_1ma_sitn_attr_get  (OPC_IMA_OOUBLE, 

’total_offered_load* .  &Offered_Load) ; 
op_i ma_s  1  ni_a ttr_get  ( 0PC_IMA_D0UBLE . 

''asynch_offered_load* .  &Asynch_Offered_Load) ; 

(Appendix  G,  line  299) 


and  added  to  the  on  screen  menu  with  the  commands; 


op_stat_scalar_wr1te  ("Total  Offered  Load  (Mbps)", 
Offered.Load) ; 

op_stat_sca1ar_wr1te  ("Asynchronous  Offered  Load  (Mbps)", 
Asynch_0f f ered.Load ) : 


(Appendix  G,  line  305) 

This  code  in  Appendix  G  contains  a  warning  to  the  user  that  the  ofifered  load 
settings  are  not  automatically  updated  in  any  vmy.  If  the  user  desires  to  plot  throughout  or 
dday  as  a  funcdon  of  ofoed  load  over  a  series  of  simulations,  then  the  user  must  remember 
to  keep  the  offered  load  assignments  current  in  the  Environment  file  for  each  simulation. 


D.  BRIDGE  LINK 

The  alteration  described  here  represents  a  simple  first  step  toward  a  network  interface. 
Instead  of  destroying  fiames  after  they  are  received,  one  station  on  the  LAN  is  modified  to 
hold  its  packets  in  subqueues.  Further  development  will  bring  about  a  protocol  for  removing 
these  buffered  packets  fi’om  the  original  LAN  and  transferring  them  to  another. 
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1.  Station  Model  Modifications 

The  received  frames  are  stored  in  subqueues  according  to  their  priority  in  a 
manner  analogous  to  that  already  described  for  the  mac  node.  This  requires  that  the  s  i  nk 
node,  1 1  c_s i  nk,  be  changed  from  its  original  processor  form  into  a  queue  node.  To  affect 
this  modification  to  the  station  model,  the  following  steps  are  followed: 

1.  The  sink  node  is  selected  by  placing  the  cursor  over  it  and  clicking  the  left 
mouse  button. 

2.  The  node  is  removed  by  invoking  the  "Cut"  icon.  The  "Packet  Stream" 
between  the  s  1  nk  and  the  mac  also  disappears. 

3.  The  "Create  Queue"  icon  is  selected,  and  the  resulting  box  is  dragged  to  the 
location  just  vacated.  Clicking  the  left  mouse  bunon  places  the  new  node  The 
station  now  has  a  queue  node  rather  than  a  processor  node. 

4  The  on-screen  attributes  menus  is  called  with  the  right  mouse  button,  and  the 
fields  are  all  set  to  the  same  values  that  were  in  effect  before,  including  the  node 
name. 

5.  The  "process  model"  field  will  be  set  to  the  newly  modified  sink  process 
model.  If  the  process  has  not  yet  been  modified,  then  the  original  assignment 
may  be  used,  then  changed  when  the  process  has  been  modified  and  saved  under 
a  new  filename. 

6  The  "subqueues"  field  is  set  to  <9>,  accommodating  eight  levels  of 
asynchronous  traffic  and  also  synchronous  traffic. 
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7.  The  packet  stream  line  between  the  s  1  n k  and  the  ma  c  nodes  must  be  replaced. 

8.  The  new  station  model  is  saved  under  a  new  filename,  for  example, 

<  'fdd1_sink_link’>. 

Figure  23  shows  the  resulting  station  model,  with  the  appropriate  on-screen 
attributes  menu. 

2.  Process  Model  Modifications 

The  changes  to  the  process  modd  code  are  few,  and  are  included  in  Appendix  G 
as  inactive  code  ("commented  out").  The  code  that  destroys  received  packets; 


op_pk_destroy  (pkptr): 


(Appendix  G,  line  98) 


is  replaced  by  code  that  enqueues  the  packets  according  to  their  priority  settings: 


op_subq_pk_insert  (pri_set.  pkptr,  0PC_QP0S_TAIL) : 

(Appendix  G,  line  105) 

The  user  should  realize  that  for  the  moment,  no  more  code  exists  for  the 
disposition  of  these  enqueued  packets;  a  loi%  simulation  simply  accumulates  packets  and  fills 
computer  memory.  The  subqueues  are  infinite  by  default,  but  may  be  limited  (using  another 
on-screen  menu)  to  demonstrate  overflows.  In  that  case,  there  is  no  code  for  the  disposition 
of  packets  that  are  lost  through  buffer  overflow,  and  these  will  simply  accumulate  in  the  host 
computer's  memory  as  well.  In  sum,  the  user  must  be  aware  of  the  memory  demands  of 
OPNET*  simulations. 
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Figure  23.  Modified  Station  Model,  "fddi  sinkjink" 


76 


E.  MULTICAST 


1.  Overview 

Multicast  is  the  addressing  of  a  packet  to  more  than  one  station.  Broadcast  is  a 
special  with  the  transmission  of  the  packet  to  all  stations.  In  the  original  model,  a  station 
desiring  to  send  the  same  message  to  all  stations  would  repeat  the  packet  transmission  for 
each  destination  station.  Actually,  this  last  is  an  abstraction;  OPNET*  simply  generates 
packets  from  each  station  addressed  to  randomly  generated  destinations,  with  no  indication 
that  any  particular  transmission  represents  a  copy  of  any  previous  transmission.  However, 
the  fact  remains  that  each  packet  is  addressed  to  only  one  station.  In  the  actual  FDDI 
protocol,  each  packet  is  passed  from  station  to  station  until  it  reaches  its  destination,  but  then 
continues  past  its  destination  until  it  is  finally  removed  from  the  ring  by  its  originating  station. 
The  OPNET*  simulation  economizes  on  the  number  of  simulation  events  (and  therefore  the 
simulation  time)  by  having  the  destination  stations  remove  the  packets  they  receive.  This 
occurs  in  the  mac  state  FR.REPEAT,  which  also  contains  comments  suggesting  that  the  user 
may  wish  to  overrule  this  economizing  feature  in  the  event  that  group  addressing  is  desired. 
Figure  24  is  the  State  Transition  Diagram  for  the  mac  process,  repeated  from  Figure  6  for  the 
reader's  reference.  The  state  FR_STRI  P  includes  the  code  by  which  an  originating  station 
removes  packets  that  have  completed  a  circuit  of  the  LAN.  It  is  not  used  in  the  original  code, 
nor  will  it  be  used  in  the  modifications  described  here. 
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The  basic  idea  is  as  foOows;  rather  than  carry  a  destination  address,  each  packet 
carries  an  array  with  a  nund>er  of  dements  equal  to  the  number  of  stations  on  the  ring.  These 
elements  are  simply  ones  and  zeros,  with  a  one  indicating  by  its  location  that  the  packet  is 
addressed  to  a  station  corre^nding  to  that  location.  For  exan^)le,  in  a  five  station  LAN,  the 
address  fidd[0  10  1  l]  would  indicate  the  packet  is  addressed  to  stations  one,  three,  and 
four  (as  in  the  case  of  indexing  vector  array  elements,  the  stations  on  an  N-station  LAN  in 
OPNET*  are  numbered  fi'om  zo-o  to  N-1).  As  the  packet  is  passed  around  the  LAN,  each 
station  inspects  this  array,  passing  the  packet  on  if  the  station  is  not  designated  a  destination 
address.  Destination  addresses  keep  a  copy  of  the  packet's  information,  set  their  place  in  the 
addire!«  fidd  to  zero,  then  pass  the  packet  on  to  the  next  station.  The  last  destination  address 
will  destroy  the  packet  after  verification  that  only  zeros  remain  in  the  destination  address 
array,  thereby  preserving  some  of  the  economy  gained  in  minimizing  the  number  of  events  in 
the  simulation.  While  the  destination  address  array  would  need  to  be  transported  with  each 
packet,  OPNEl^s  Kernel  Procedures  can  only  accommodate  a  pointer  to  the  array.  The 
following  sections  describe  the  changes  necessary  to  effect  multiple  addressing.  The  reader 
is  again  referred  to  Appendices  E,  F  and  G,  containing  the  ".C"  files  for  the  MAC,  source,  and 
sink  process  models,  respectively.  However,  the  implementation  of  multicasting  involves  no 
changes  to  the  sink  process  model. 
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2.  Environment  File 


Each  station  is  assigned  a  nuudnuim  and  a  minimum  number  of  possible 
destination  addresses  to  use  in  addressing  each  packet.  The  following  are  added  to  the 
Environment  file; 


■*.*. 1 lc_src.min  num  addees":  <user  assigned  integer> 
**.*.1 lc_src.max  nura  addees":  <user  assigned  integer> 

These  will  be  called  by  the  source  process  model's  INTT  state,  i^pendix  H 
contains  an  exa^^)le  Environment  file  including  these  new  attributes.  The  minimum  number 
must  be  at  least  one,  and  the  maximum  should  be  no  greater  than  N-1,  where  N  is  the  number 
of  stations  (the  logic  written  in  the  source  model's  code  does  not  allow  stations  to  address 
packets  to  themselves),  if  it  is  desired  that  some  station  generate  no  traffic,  then  the 
"arrival  rate"  field  should  be  set  to  zero.  Setting  "min  num  addees"  and  "max  num 
addees"  to  zero  will  only  result  in  packets  transmitted  with  no  destination  addresses 
assigned.  Setting  "max  num  addees"  to  a  number  greater  than  N-1  will  cause  an  endless 
loop  in  the  code  that  generates  destination  address  assignments  in  the  source  process  (the 
logic  in  the  loop  is,  "assign  x  different  destinations,  but  do  not  repeat  any  "). 

3.  Station  Model 

The  additions  to  the  environment  file  must  be  added  to  the  station  model  in  the 
Node  Editor,  in  a  manner  analogous  to  the  method  described  in  the  discussion  of 
prioritization  (in.B.4.a.  Station  Model  Changes).  The  steps  required  to  add  another  attribute 
to  the  on-screen  menu  are  not  recounted  here,  but  the  desired  final  result  is  shown  in 
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Figure  25.  It  is  a  good  practice  to  save  the  changed  station  modd  under  a  new  name,  for 
example  <  ‘  fddi_s  ta_mu  lt'>.  until  the  user  is  certain  that  the  modifications  do  more  good 
than  harm  to  the  origiiud  modd. 

4.  Source  Process  Modd 

A  real  packet  on  a  real  LAN  would  necessarily  be  self*  contained,  carrying  with 
it  all  its  destinatimi  addresses.  However,  the  iimctions  used  to  assign  the  packet  address  field 
in  OPNET*  will  not  support  a  vector  structure,  and  so  pointers  to  memory  locations  must  be 
used,  with  these  memory  locations  containing  the  destination  addresses.  The  modifications 
to  the  source  process  to  effect  multiple  addressing  are  sununarized  in  the  following  sections. 
As  is  the  case  with  the  station  node  modd,  each  of  the  process  models  should  be  saved  under 
new  names,  for  example  fddl.gen.mult,  as  a  nutter  of  practice. 
a.  Variables 

To  begin,  a  global  variable,  NUM.STATIONS,  is  defined  in  the  Header  Block 
(h  is  also  defined  in  the  mac  process  modd),  to  be  used  as  a  loop  counter.  This  variable  must 
be  kept  updated  to  accuratdy  reflect  the  correct  number  of  stations  on  the  FDDI  LAN.  This 
is  easily  forgotten  when  different  LANs  are  created,  using  the  same  station  model  with 
different  numbers  of  stations. 

As  was  mentioned,  the  destination  address  fidd,  originally  a  single  integer 
value,  must  now  be  nude  a  pointer  to  an  array  of  integers.  Although  "C"  programming 
language  treats  the  name  of  a  vector  array  as  the  array's  pointer,  the  established  Kernel 
Procedures  do  not  support  the  simple  change  of  syntax.  In  short,  a  new  variable,  *da_ptr 
(destination  address  pointer),  is  declared  as  an  integer  pointer  in  the  Temporary  Variables 
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Figure  25.  Multicast-Ci^>able  FDDI  Station  with  Attributes  Menus 


(TV)  edhOT.  The  original  variable,  dest.addr,  is  removed  frcxn  the  TV  section,  and  declared 
with  the  State  Variables  (SV)  as  an  array  of  int^ers,  with  dimensions  C  NUM.ST  AT  I  ON  S  +  l  ] 
In  addition,  variables  to  accompany  the  Environment  file  attributes  are  declared  with  the 
State  Variables:  min.num.addees  and  max_num_addees.  The  resemblance  between  these 
variables  and  the  attributes  they  accompany  is  meaningless  in  respect  to  "C  language  syntax, 
but  is  of  course  a  usefiil  memory  aid  to  the  user.  The  pointer  num_addees_dist_ptr 
represents  the  value  used  in  determining  stochastic  values.  Also,  the  integer  num.addees  is 
declared  in  the  State  Variables,  to  represent  the  number  of  stations  to  which  a  given  packet 
will  be  assigned.  It  is  used  as  a  loop  counter,  and  will  be  different  for  each  packet. 
b.  ImttaUzadoH  State 

In  the  source  model's  Initialization  state,  the  range  bounding  the  number 
of  destination  addresses  is  determined  with  a  call  to  the  Environment  file: 

op_ima_obj_attr_get{my_i<l,  'min  num  addees’. 

&mi n_num_addees ) : 

op_ima_obj_attr_get(my_id.  'max  num  addees" . 
&max_num_addees ) ; 

(Appendbc  F,  line  86) 
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These  resuh  in  the  assignment  of  the  values  from  the  Environment  file  to 
the  adthesses  of  the  corre^KMiding  variables.  A  distribution  is  established  with  the  following; 

num_addees_dist_ptr  -  op_dist_1oad  ( "uni form_i nf , 
min_num_addees.  max_num_addees ) ; 

(Appendix  F,  line  1 14) 

This  value  is  used  to  genome  streanos  of  stochastic  values,  and  is  used  in 
the  ARRIVAL  state. 

c.  ••ARRIVAL*’ State 

In  the  ARRIVAL  state,  the  actual  number  of  stations  to  receive  the  new 
packet  is  determined,  and  then  a  loop  is  used  to  choose  these  stations  one  at  a  time  Each 
loop  iteration  is  very  similar  to  the  original  procedure  that  was  in  place  when  only  one  station 
was  assigned  to  each  packet  The  loop  contains  a  provision  to  prevent  the  repeated 
assignment  of  the  same  station,  and  also  to  prevent  the  assignment  of  the  originating  station 
as  a  destination  address  The  following  statement  determines  the  number  of  destination 
addresses  for  a  given  packet 

num_acdees  •  op_dist_outcome  (nun)_addees_di  st_ptr) ; 

(Appendix  F,  line  172) 
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The  foUowing  loop  is  used  to  find  and  assign  the  chosoi  stations; 


for  (i  -  num  addees:  i  >  0;  1--) 

{ 

gen_packet: 

n1x  -  op_dist_outcome  (dest_d1st_ptr ) ; 

1f  (dest_addr[n1x]  —  1  ||  nix  —  station_addr ) 

{ 

goto  gen_paclcet; 

} 

dest_addr[n1x]  -  1: 

} 

(Appendix  F,  line  174) 

This  loop  continues  to  iterate  until  the  specified  number  of  stations,  without  repetition,  is 
assigned. 

Recall  that  the  destination  address  array  is  declared  with  one  element  more  than  the 
number  ofstations  in  the  LAN  (dest.addr  [NUM_STATI0NS  1]).  Here,  all  the  elements 
in  the  destination  arr^  must  be  shifted  one  ^Mce  to  the  right,  and  a  simple  loop  is  used  to  set 
dest_addr[1-)-i]  equal  to  dest_addrCl  ],  for  1  iterations.  This  step  is  necessary  because 
the  first  array  element  will  be  overwritten  with  the  array's  memory  address  in  the  course  of 
the  packet's  travels,  as  it  is  transmitted  fi'om  one  station,  received  by  the  next,  and  its 
destination  address  field  is  opened,  inspected,  then  closed  by  each  station  in  turn.  This 
behavior  is  verified  by  use  of  the  d^ug  tool  set  to  "full trace,"  accompanied  by 
strategically  placed  pr1  ntf  statements.  The  author  does  not  pretend  to  know  why  this 
happens.  The  array  element  shift  is  a  deft  enough  way  to  sidestep  the  problem.  However, 
all  references  in  other  states  to  the  destination  address  array  must  be  ofi^  to  accommodate 
this  shift. 
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5.  MAC  Process  Model 


Tlje  MAC  process  model  receives  each  packet,  inspects  it,  the  decides  whether 
or  not  the  packet  is  addressed  to  the  station.  In  the  original  model,  the  packet  is  removed 
fix)m  the  ring  by  the  destination  station,  and  relayed  by  other  stations.  With  multicasting  of 
packets,  a  third  case  arises,  in  which  a  station  receives  a  packet  addressed  to  it,  but  must  also 
pass  the  packet  on  to  other  destination  stations.  A  number  of  print  commands  are  placed  in 
the  code,  but  left  inactive.  They  are  of  much  use  in  the  verification  of  the  model's  operation. 

a.  Variables 

The  same  variable  NUM.STaTIONS  used  in  the  source  model  is  also  defined 
in  the  Header  Block  of  the  MAC.  The  user  must  remember  to  keep  this  value  updated  in  both 
places  when  the  same  station  model  is  used  in  a  different  size  LAN  The  destination  address 
is  changed  from  an  integer  into  an  open-ended  array  of  integers,  dest.addrC],  in  the 
Temporary  Variables  editor.  An  integer  pointer,  *da_ptr,  is  declared  as  well. 

b.  Encapsulation  State 

The  Encapsulation  state  receives  frames  from  the  source  process,  and  place 
them  inside  the  format  f  d d  i  ^ma  c_f  r  for  transmission  on  the  LAN.  An  intermediate  step  is 
to  inspect  the  frame  received  from  the  source  for  its  destination  address,  which  must  be 
written  into  the  encapsulating  frame's  destination  address  field  as  well.  The  original 
statement; 


op_ici_attr_get  (ici.ptr,  "dest.addr",  &dest_addr): 
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is  unworkable  with  dest.addr  inarray  form,  which  is  why  the  pointer  *da_ptr  is  declared. 
Instead,  the  following  is  used. 

op_ici_attr_get  (1ci_ptr.  *dest_addr'.  &da_ptr); 

(Appendix  E,  line  806) 

followed  by  a  loop  assigning  each  element  in  the  array  a  value  from  the  corresponding 
Hqwent  in  the  array  found  at  address  da_ptr.  Vol.  S  O,  SimuJation  Kernel Maamal,  discusses 
this  command  statement.  This  loop  uses  as  a  counter  the  value  NUM_STATIONS-»-l,  for  the 
reason  mentioned  earlier;  use  of  a  pr  1  ntf  statement  would  reveal  that  the  first  element  in 
the  array  has  been  written  over  and  rq)laced  with  a  number  representing  the  memory  address 
of  the  array.  Fortunately,  the  entire  original  array  of  zeros  and  ones  has  been  shifted,  so  the 
first  element  is  intact.  Correspondingly,  all  references  to  the  array  firom  within  the  MAC 
process  must  be  made  with  respect  to  this  sl^. 
c.  Frame  Rqteat  State 

The  Frame  Repeat  state  inspects  each  received  packet  and  acts  on  one  of 
three  cases:  the  packet  is  addressed  only  to  this  station,  or  the  packet  is  not  addressed  to  this 
station  at  all,  or  the  packet  is  addressed  to  this  station  and  to  other  stations  as  well.  The  first 
two  cases  are  already  present  in  the  original  model,  and  require  some  simple  modifications. 
The  third  case  represents  a  significant  change,  requiring  the  addition  of  an  entire  block  of 
code  to  the  state,  in  which  the  packet  information  is  copied  first,  then  passed  on  to  the  next 
station. 
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The  first  statement  in  the  FR_REPEAT  state  (^)ens  the  arriving  padcet's 
address  field  for  inspection: 

op_pk_nfd_get  (pkptr,  ’dest_addr’ ,  ida_ptr); 

(Appendix  E,  line  604) 

Here,  &da_ptr  has  been  substituted  for  the  original  &dest_addr.  As  is  the  case  in  the 
ENCAP  state,  the  arriving  poiitter  is  used  to  initialize  the  locally  hdd  destination  address 
array: 

for  (1-0;  1  <  NUM_STATI0NS+1:  1++) 
dest_addr[1]  -  da_ptr[1]: 

(Appendbc  E,  line  610) 

This  destinarion  address  array  is  then  passed  through  a  loop  to  determine  if  it  has  more  than 
one  destination  address,  and  to  see  if  the  element  corresponding  to  this  station  is  set  to  one, 
indicating  the  packet  is  addressed  to  this  station.  If  the  packet  proves  to  be  addressed  to  this 
station  only,  then  the  actions  of  the  originai  code  are  carried  out:  rdevant  fidds  are  copied 
to  an  ICI  packet  format  for  transmisaon  to  the  sink  process,  then  the  packet  is  destroyed. 
If  inspection  of  the  destination  address  am^  shows  the  packet  is  not  addressed  to  this  station 
at  all,  the  original  code  is  again  suffident  to  place  the  packet  back  on  the  ring. 

The  third  case  represents  a  new  situation.  When  the  packet  is  addressed 
to  this  station  and  to  others  as  well,  the  information  must  be  saved  here,  and  be  transmitted 
onto  the  ring  again.  These  actions  are  carried  out  with  commands  borrowed  fi’om  the  first 
two  cases,  and  include  some  new  considerations  as  wdl.  The  function  "op_pk_nfd_get()" 
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is  used  to  retrieve  data  from  specified  fields  in  the  packet.  That  is,  it  is  a  decapsulation 
fimction.  When  the  data  happens  to  be  in  a  structure  format,  the  fimction  has  the  effect  of 
destroying  the  information.  This  is  an  in^rtant  point  because  the  information  must  be 
preserved  for  retransmission.  Therefore  the  function; 

op_pk_nfcl_get  (pkptr,  "Info*.  &data_pkptr)  ; 

(i^ipoidix  E,  line  719) 

must  be  followed  at  some  point  with  the  statement; 

1nfo_ptr  -  op_pk_copy  {data_pkptr) : 

(Appendix  E,  line  727) 

in  which  1  nf  o.ptr  has  been  declared  in  the  Temporary  Variables  to  have  the  same  type  as 
the  structure  in  the  "  1  nf  o"  field.  When  this  information  is  summoned  for  re-encapsulation 
with  the  function; 

op_pk_nfd_set  (pkptr.  *info".  info_ptr); 

(Appendbc  E,  line  747) 

the  fidd  information  has  been  preserved.  The  other  fields,  "src.addr",  "dest.addr",  and 
"prl",  do  not  require  this  procedure,  since  they  are  not  lost  with  decjqrsulation.  Two 
packets  resuh;  one  is  an  ICI  fiame  carrying  the  received  information  to  the  sink  process,  and 
the  other  is  a  re-encapsulated  packet  sent  to  the  LAN.  The  station's  last  action  before 
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re-cncapsulating  the  destination  address  amy  is  to  zero  its  corresponding  address  dement. 
The  last  station  to  receive  the  packet  win  destroy  h,  upon  determining  that  only  zeros  remain 
in  the  destination  address  array  (Appendix  E,  lines  644  and  692). 

6.  Limitation 

The  primary  limitation  of  the  model  with  multicasting  active  is  in  the  generation 
of  throughput  and  delay  statistics.  As  the  code  currently  stands,  eadi  packet  is  counted  by 
every  station  that  receives  it,  leading  to  muhiplication  of  througlqnit  data.  On  the  other  hand, 
some  use  nuy  possibly  be  made  of  this  characteristic  by  comparing  tl»  tallied  throughput 
against  the  actual  offixed  load,  as  a  measure  of  the  effectiveness  of  the  rmilticastii^  scheme. 
For  example,  a  measured  throughput  of  100  Mbps  versus  a  known  offered  load  of  SO  Mbps 
could  indicate  that  multicasting  effectivdy  generates  SO  Mbps  vnthout  physically  taxing  the 
bandwidth  capability  of  the  FDOI  LAN,  since  no  additional  packets  are  generated. 
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IV.  MODEL  TESTING 


This  chapter  provides  several  test  results  intended  to  verify  the  enhanced  capabilities 
added  to  the  basic  FDDI  station  nxxld  in  OPNET*.  In  addition  to  inq)roving  the 
performance  and  display  features,  the  modifications  must  preserve  the  basic  behavior  to  be 
useful.  The  tests  presented  here  include  an  illustration  of  the  model's  treatmem  of 
synchronous  and  priority>based  asynchronous  traffic,  a  simple  demonstration  that  the 
modified  sink  pro^eu  does  indeed  store  the  traffic  h  receives,  a  check  against  theoretical 
performance  equations,  and  a  demonstration  on  the  monitoring  of  multicast. 

Not  all  of  the  modifications  described  in  this  thesis  are  incorporated  simultaneously 
in  all  station  models.  The  State  Transition  Diagram  correction  to  the  original  f dd ^  sink 
process  modd  is  of  course  installed  in  all  modds  that  use  the  1 1  c_s  1  nk  node.  Likewise, 
the  patch  for  OPBUG  is  mstalled  for  all  MAC  modd  versions.  The  generation  of 
randomly  differing  priority  assignments  for  aU  packets  is  dosely  interrdated  to  the 
generation  of  output  statistics  segregated  by  class  and  priority;  both  involve  extensive 
modifications  to  the  original  process  modds  for  the  source,  sink  and  MAC,  whidi  are 
stored  as  fdd1_gen,  fddl.mac,  and  fddl.sink.  (The  actual  file  names  found  in  the 
UNIX  subdirectory  have  the  suffix  ".pr.m,”  and  when  these  are  conq)iled, 
corresponding  files  with  the  suffix  ".pr.c”  are  created.)  The  origiiud  models  of  those 
names  are  retired  under  the  ending  ".orlg.pr.m."  Likewise,  the  original  node-levd 
station  is  stored  uixler  the  name  fdd1_sta_or1g,  whUe  fddl.statlon  is  the  upgraded 
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versKNL  The  muhicastiiig  capability  is  stored  in  a  separate  station  model,  fdd  l_sta_mult, 
\tMch  includes  the  processes  fdd1_fflac_mu1t,  fdd1_gen_niu1t,  and  fdd1_s1nlc_mult,  and 
contains  all  of  the  other  modifications  as  wdl.  The  multicast  aq)ability  was  the  last  feature 
installed  for  this  thesis,  and  has  not  been  completely  developed. 

A.  SYNCHRONOUS  THROUGHPUT 

1.  Overview 

This  test  was  motivated  by  an  eariier  study,  in  vt^ch  a  software  simulation  tool 
was  used  to  demonstrate  the  effect  of  increa^g  offered  load  on  the  a^chronous  and 
synchronous  throughput  of  an  FDDI  LAN.  Using  the  Block  Oriented  Network  Simulator 
(BONeS*),  Tali  et.  al.  were  able  to  show  that  synchronous  throughput  does  not  d^rade 
appreciably,  even  when  the  offered  load  is  wdl  in  excess  of  100  Mbps.  They  were  able 
further  to  show  the  decay  in  throughput  sufiered  in  the  asynchronous  priority  levds  as  offered 
load  is  increased.  Figure  26  is  taken  from  this  study.  In  addition  to  providirig  an  idea  of 
expected  perfomiance,  this  figure  also  highlights  the  frict  that  in  its  original  form,  OPNET^s 
FDA  model  provides  no  method  to  display  any  throughput  data  other  than  the  overall 
performance  parameters,  total  throughput,  total  mean  delay,  and  total  end-to-end  dday. 

2.  Setup 

The  set  up  was  intended  to  imitate  the  older  experiment  as  closely  as  possible. 
Ten  simulations  were  conducted  using  the  same  SO-station  LAN.  Ten  stations  (f  0 .  f  5 . 
flO,  fl5.  f20.  f25,  f30,  f35.  f40.  f 45)  were  desigrutted  "cortstant**  generators. 
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Figure  26.  Throughput  Measurements  Using  BONeS*  (Tari,  et.  al.,  1988,  p.  58) 
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That  is,  they  were  nxxlified  inside  the  source  process  "C"  code  to  generate  packets  at  a 
mngtunt  rate,  rather  than  at  an  exponentially  distributed  approximation  of  the  rate  specified 
in  the  Environment  file.  These  ten  stations  transmitted  synchronous  traffic  only,  while  tte 
other  40  stations  were  allocated  no  synchronous  bandwidth,  sending  asynchronous  traffic 
only.  The  ^nchronous  stations  generated  S12-bit  packets  at  a  constant  arrival  rate  of 6000 
packets  per  second.  The  asynchronous  stations  transmitted  1000>bit  pack^,  at  a  rate 
stepped  so  as  to  increase  the  total  offisred  load  by  10  Mbps  in  each  siinulation.  Therefore, 
total  ofiered  load  ranged  firrm  40.72  Mbps  to  140.72  Mbps  over  ten  tests,  with  steady  state 
data  recorded  in  a  data  file  of  scalar  data.  TTRT  was  set  to  10.7  ms,  in  order  to  support  the 
ddayofS0statioiisonaS0kmtingwhiiemaintainit^£SAia  10ms.  This  differed  fi-om  the 
older  study,  far  which  a  TTRT  value  of  8.0  ms  was  used,  despite  the  authors'  stated  intention 
to  model  voice  network  traffic.  As  noted  by  Powers  (1993,  p.340),  synchronous  voice 
transmission  requires  that  the  token  visit  each  voice  transmitter  every  20  milliseconds, 
resulting  in  £SAi  -  10  ms.  This  in  turn  requires  TTRT  to  exceed  10  ms  by  an  amoum 
sufficient  to  accoum  for  physical  delays  inherent  to  the  ring  fiber  and  the  stations. 
Asynchronous  priority  threshold  levels.  T_Pri  [  i  ],  in  the  INTT  state  of  the  MAC  process 
code  were  set  in  increments  of  0. 125  TTRT,  so  that  Priority  1  traffic  transmission  was  cut  off 
whea  THT  incremented  to  1.3375  ms,  and  Priority  8  traffic  could  be  sem  for  the  entire  THT 
period.  Recall  that  this  incrementing  THT  is  a  fimction  of  OPNET,  reversed  fi'om  the 
decrementing  timer  described  in  most  literature. 
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3.  Results 


Figure  27  shows  a  plot  of  total  througl^t  over  a  series  of  ten  simulations  in 
OPNET,  demonstrating  a  rou^ily  hr^  rise  until  the  offered  load  begins  to  exceed  90  Mbps, 
whidi  is  in  qualitative  agreement  with  the  older  e9q>eriment,  and  agrees  with  results  published 
by  Dykeman  and  Bux  (1988,  pp.  1003-1007).  This  plot  also  serves  to  diow  off  one  of  the 
modd's  improvements  in  data  dis|riay,  allowing  "Offered  Load**  to  be  an  abscissa  for  scalar 
plots. 

Figure  28  illustrates  the  fiict  that  synchronous  bandwidth  allocation  is  not  affected 
by  the  asynchronc;; '  offered  load;  therefine,  ^nduonous  throu^^t  remains  nearly  constant 
as  the  offered  load  is  increased. 

Figures  29-3 1  illustrate  the  effect  of  increasing  offered  load  on  the  throughputs 
of  asynchronous  traffic  at  priority  levels  two,  three,  and  four,  respectively.  No  priority 
settings  above  four  suffered  any  dt^radadon  within  the  range  of  offered  load  observed  in  this 
test.  The  decay  of  Priority  3  traffic  at  approximatdy  100  Mbps  of  offered  load  suggests  that 
( Ve)TTRT  may  be  a  guiding  point  for  setting  priority  thresholds  that  will  take  effect  before 
the  LAN's  capacity  is  reached. 

B.  PRELIMINARY  LINKING  MODEL 

1.  Overview 

The  modifications  made  to  the  sink  process  as  a  step  toward  a  bridging  node  are 
the  simplest  of  all  described  in  this  thesis,  and  the  testing  of  the  finished  model  is  also  simple. 
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Figure  31.  Priority  Four  Throughput  vs.  Total  Offered  Load 
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It  is  necessary  only  to  show  that  all  the  trafiSc  transmitted  to  the  ^Ration  is  received  and  hdd. 
To  demonstrate  this  action,  a  toi-station  LAN  was  created,  with  station  f  9  designated  the 
link  node.  The  Environment  file  assignments  were  made  so  that  all  stations  directed  all  trafiSc 
to  station  f  9,  which  itself  was  not  transmitting.  A  modest  offered  load  was  used  to  prevent 
an  ovo-load  of  packets  in  the  simulation  host  computers  memory.  All  transmitting  stations 
were  assigned  the  same  fiiO  range  of  asynchronous  priority  settings,  and  were  assigned  equal 
portions  of  synchronous  bandwidth.  Each  of  the  buffers  at  station  f  9  should  have  then  been 
seen  to  receive  packets  pre-soned  for  eventual  transmission.  The  Probe  Editor  was  used  to 
monitor  "nkslze."  the  number  of  packets  in  each  subqueue  of  the  modified  sink  process 
model. 

2.  Setup 

The  following  calculations  and  Environment  file  settings  in  Table  1  were  chosen 
as  reasonable; 


Table  1  ENVIRONMENTAL  FILE  SETTINGS 


packet  size. 

2000  bits 

arrival  rate; 

10  pkt./sec. 

offered  load; 

9*  10  *  2000  «  180,000  bps. 

TTRT  (T_Req); 

0.004  sec. 

async  mix; 

0.9 

prop  delay; 

5.085  X  10““  sec  /km.  *  1  km.)  =  5.085  x-"  sec. 

station  latency; 

60.0  X  lO"®*  sec 

D_Max; 

(5.085  Msec.  •  10)  +  (60.0  xio-“  •  10)  =  0.05685  ms. 

F  Max  . 

0.360  ms. 

Token  Time; 

0.00088  ms. 

synchronous  BW; 

4-(0.05685  +  0.360  +  0.00088)  =  4  -  0.41773  =  3.58227  ms. 
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Dividing  bandwidth  evenly  among  9  stations  gives  the  following; 


-  0.39*03  msJstation.  (2) 

9  stations 


This  result  is  compared  with  TTRT  to  determine  the  "sync  bandwidth"  attribute 


.  0.0995075  ms.  P) 

4.0  ms. 


which  is  a  unitless  fraction  of  TTRT. 
3.  RESULTS 


The  given  parameters  were  applied,  and  the  receiving  buffers  were  inspected  at 
the  end  of  one  second  of  simulation  time.  Figure  32  is  the  plot  obtained  illustrating  the 
accumulation  of  packets  in  ail  nine  subqueues.  (Although  all  the  plots  may  be  placed  in  one 
pand,  the  data  are  divided  into  two  panels  for  readability  of  the  hardcopy).  The  plots  show 
the  following  after  one  second; 


Tabk2.  SUBQUEUE  ACCUMULATION 


subqueue(O) : 
subqueue( 1 ) : 
subqueue(2) : 
subqueue(3) : 
subqueue(4) : 
subqueue(5) : 
subqueue(6) : 
subqueueC^ ) : 
subqueueCS) : 


13  packets 

11  packets 

10  packets 
7  packets 
7  packets 

12  packets 

11  packets 
10  packets 

9  packets 


total :  90  packets 


This  agrees  with  the  given  packet  generation  rate  of  90  packets/sec.,  and  verifies  that  the 
preliminary  linking  model  holds  all  received  packets  on  station. 
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Figure  32.  Packet  Accumulation  at  Linking  Model  "fddi_sink_Iink" 


101 


C.  SYNCHRONOUS  TIMING 

1.  Overview 

In  order  to  preserve  the  real-time  nature  of  ^nchronous  traffic,  the  bandwidth 
allocated  to  a  given  station  may  not  be  esmeeded.  Although  transmission  time  (bandwidth) 
may  remain  to  a  station,  the  protocd  detennines  a  piiori  wfaeAer  the  next  packet  transmission 
would  cause  the  allotted  bandwidth  to  be  exceeded.  If  the  bandwidth  limit  would  be 
exceeded,  then  the  station  will  not  transmit.  The  code  in  the  TX.DATA  state  of  the  MAC 
process  ensures  OPNEl^s  FDDI  LAN  modds  adhere  to  this  bdiavior,  as  shown  in  the 
following  simple  oqieriment. 

2.  Setup 

A  new  LAN  was  created,  uang  13  stations  on  91  km.  of  fiber,  resulting  in  seven 
kilometers  of  fiber  between  stations.  The  odd  figures  were  chosen  in  order  to  avoid 
symmetries  in  the  arithmetic  involved,  therd^y  enhancing  the  instiuctiond  value  of  the  test. 
All  13  stations  were  assigned  an  equal  portion  of  the  total  available  bandwidth  for 
synchronous  traffic,  and  afl  stations  transmitted  only  synchronous  traffic.  Physical  attributes 
were  identical  for  each  station.  The  following  calculations  apply; 
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Table  3  B-STATION  LAN  ENVIRONMENT  SETTINGS 


prop_delay: 

7  km.  •  5.085  x  10-^  sec./km.  =  0.0355950  ms 

station  latency; 

60.0  X  lO"*  sec./station 

F  Max: 

0.360  ms. 

D_Max : 

(13  stations  •  60.0  x  lo**  sec./station)  +  (13  links  • 
0.035595  ms./link)  =  0.4627428  ms. 

Token_Time : 

0.88  /isec. 

D_Max  +  F_Max  +  Token_Time  =  0.8236228  ms. 

TTRT: 

4.0  ms. 

TTRT  z  ISAj  +  0.8236228  -  ^SAj  s  3.1763772  ms. 

Divide  the  synchronous 

allotment  evenly  among  13  stations; 

3.1763772  ms./  13  stations  =  0.2443367  ms./station. 

Given  the  standard  transmission  rate  of  100  Mbps,  each  station  may  transmit 
24,433  bits  whh  its  synchronous  allotment.  This  bandwidth  is  converted  to  a  fraction  for  the 
Environment  file  attribute  "sync  bandwidth": 

0^443367  ms.  ,  o  og,og4ig  (4) 

4.0  ms. 


For  this  test,  all  stations  were  constant  transmitters.  That  is,  the  code  for  the 
source  process  was  adjusted  so  that  packet  transmission  rates  and  packet  lengths  were 
assigned  invariant  values,  rather  than  stochastic  approximations  of  the  attributes  assigned. 
A  TTRT  of  4  ms  indicates  2S0  token  passes  per  second,  which  was  chosen  as  the  packet 
arrival  rate  for  all  stations.  Packet  size  was  24,000  bits,  resulting  in  a  total  offered  load  of 
78.0  Mbps.  A  larger  packet  size,  for  example  25,000  bits,  should  be  too  large  to  transmit, 
resulting  in  no  throughput  at  all. 
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3.  Results 

Figure  33  shows  the  resulting  total  throughput  derived  from  the  given  setup. 
Invddng  die  "convert  to  text”  attribute  of  the  on-screen  menu  indicates  a  value  of  77.7 
Mbps  after  one  second,  widi  a  slow  rise  sdll  in  progress.  This  is  in  dose  agreement  with  the 
offered  load. 

Figure  34  is  an  en^ty  panel,  accompanied  by  a  text  screen  indicating  that  no 
througlqnit  results  when  the  packet  size  exceeds  that  allowed  by  the  synchrono”<;  bandwidth 
assignment.  In  this  case,  packet  size  was  increased  to  25,000  bits.  Arrival  was  also 
reduced  to  100  packets/sec.,  resulting  in  a  total  offered  load  of  32.S  Mbps.  Figure  35 
illustrates  the  accompanying  accumulation  of  packets  in  station  f  3's  subqueue(8),  udiich  is 
reserved  for  synchronous  traffic.  The  perfectly  linear  shape  is  a  result  of  the  constam  arrival 
rate  assignment. 

D.  ASYNCHRONOUS  EFFICIENCY 

1.  Overview 

A  network's  throughput  efficiency  is  calculated  from  the  following  equations, 
which  assume  that  only  asynchronous  traffic  is  bong  transmitted: 
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E  ■ 

{TN*D) 


(5). 


Di^wre: 

number  of  stations, 
r»TTRTand, 

D  »  ring  latency  (total  «i*ng  required  for  a  token  to  circulate  die  ring  in  the 
absence  of  data  traffic). 

Ring  latency  D  is  in  turn  defined  as 

D  -  I(")  ♦  W 

c 

where: 

L  ~  length  of  ring  in  kdlometers 
%  =  5.085  X  l(r“sec./ni. 

=  token  processing  time  (0.88  ^(S.) 

(Powers,  1993.  pp.  336-337;  uses  T,  -  1.0  ^ts.  as  a  typical  value) 

The  same  13  station,  91  km  LAN  described  previously  was  used  here,  with  the  Environment 
file  adjusted  so  that  no  synchronous  bandwidth  was  assigned,  and  only  asynchronous  traffic 
was  generated.  Offered  load  was  78.0  Mbps.  The  given  equations  indicate  the  expected 
efficiency  is  87.44%. 
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2.  Rcsnlti 


Figure  36  illustrates  the  resulting  throughput,  68.48  Mbps,  which  is  87.79%  of 
the  offered  load.  This  agrees  quite  wdl  with  the  predicted  througl^Hit. 

E.  MULTICASTING 

1.  Overview 

The  multicasting  function  is  deagned  to  assign  to  each  packet  a  randomly  chosm 
number  of  destination  addresses,  then  to  use  this  sdected  number  as  an  index  for  a  loop  in 
vdudi  a  different  destination  address  is  assigned  on  each  iteration.  Upon  completion  of  the 
loop,  a  vector  arn^r  of  ernes  and  zeros  has  been  created,  in  i^ch  a  one  in  position  /  indicates 
the  packet  is  addressed  to  station  f Of  course,  a  real  transmitter  would  send  many 
consecutive  packets  to  the  same  set  of  addresses,  in  streams  that  comprise  messages. 
However,  this  modification  is  in  keeping  with  the  original  nx)dd's  actions,  i^ch  randomly 
assigned  destinations  on  a  packet-by-packet  basis. 

Prdiminaiy  tests  indicated  the  model  is  not  fully  developed.  Because  no  change 
was  made  to  the  statistics  generation  mechanism  in  the  sink  process  model,  the  new  model 
as  written  should  have  resulted  in  packets  being  counted  toward  total  throughput  each  time 
they  were  received  at  a  de^ination,  giving  an  inflated  throughput  computation.  On  the  other 
hand,  this  inflated  figure  could  possibly  be  of  value  as  a  measure  of  "virtual  throughput."  In 
any  event,  tests  indicate  that  throu^iput  statistics  are  not  being  coimted  correctly.  However, 
a  study  of  the  modd's  bdiavior  using  the  debug  tool  in  coi^unction  with  "prl  ntf "  staternems 
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Figure  35.  Accumuladng  Synchronous  Packets  in  MAC 
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Figure  36.  Asynchronous  Throughput 
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indicited  thst  no  packets  were  being  lost,  and  all  stations  seemed  to  cany  out  correctly  the 
operatxm  of  receiving  a  multicast  packet,  saving  the  information,  and  passing  the  packet  on 
to  the  next  station. 


Three  tests  are  described  here.  The  first  is  an  atten^^t  to  reproduce  the  results 
^nerated  fisr  one  of  the  simulations  used  in  Section  A,  then  uses  the  same  iiqxit  parameters 
to  see  if  ai^  differences  exist  in  the  handling  of  synchronous-only  and  asynchronous-only 
traffic.  The  second  test  compares  all  synchronous  throu^qxit  with  all  asynchronous 
throu^out.  The  third  test  is  a  verification  that  no  packets  are  actually  being  lost.  Thefourth 
test  is  an  attempt  to  generate  a  plot  of  expected  throughput  \idien  one  station  broadcasts  all 
its  traffic. 

The  tests  generally  mdicate  that  the  multicast  capable  model,  when  limited  to 
an^e  addressing,  does  not  bdiave  in  the  same  manner  as  the  single-address-only  model.  In 
particular,  througlpjt  is  lower  than  expected.  Further  devdoprnem  will  be  necessary  to  make 
the  multicasting  model  a  reliable  tool. 

2.  First  Test 
a.  Setup 

Figure  37  di^lays  the  throughput  plots  resulting  from  the  third  run  in  the 
set  of  simulations  used  to  construct  Figure  27.  This  test  is  based  on  the  idea  that  if  the 
multicast-capable  modd  is  limited  to  sin^e  addresang,  and  given  the  same  input  parameters 
provided  in  the  earlier  test,  then  the  resulting  throughput  ought  to  be  identical  for  total 
asynchronous  and  synchronous  traffic.  Therefore,  the  following  inputs  were  used  for  a  SO 
station,  SO  km.  LAN  using  the  multicasting  station  model. 
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Tea  stations (fO .  f5.  flO.  fl5.  fZO.  f25.  f30.  f35.  f40.  f45) 
transnnit  only  ayndironous  traffic  in  S12-bit  packets  with  a  constant  arrival  rate  of  6000 
packets/sec,  resulting  in  a  synchronous  offered  load  of  30.72  Mbps.  The  renuuning  40 
stations  transmit  asynchronous  traffic  only,  in  lOOO-bh  packets  at  an  arrival  rate  of  750 
packets/sec,  for  an  asynchronous  offered  load  of  30  Mbps.  TTRT  is  set  to  10.7  ms.  For  all 
stations,  the  Environment  file  attributes  "nln  nun  addees"  and  "max  nun  addees"  are 
both  set  to  1,  enforcing  the  limit  of  one  destination  address  per  packet.  A;^>endix  H  ws 
the  Environment  file  used  here. 
h.  Results 

Figure  38  illustrates  the  resulting  throughput.  Table  1  summarizes  the 
throughput  results  for  the  two  simulations.  Hie  unpredictable  throughput  of  the  multicast- 
capable  model's  synchronous  and  asynchronous  modes  would  suggest  some  logic  error  in 
coding.  The  reduction  in  overall  throughput  suggests  perhaps  some  difficulty  with  the 
simulation's  timing  mechanism. 


Tabled  THROUGHPUT  COMPARISON,  FIRST  TEST 


Offered  Load 

Single  Address 
Capable 

Multicast 

Capable 

Total 

ISESESSSm 

BSSEESflU 

30.72  Mbps 

30.80  Mbps 

43.00  Mbps 

Asynchronous 

30.00  Mbps 

12.00  Mbps 

A  real  FDDI  station  would  not  generate  destination  addresses  in  the  maimer 
coded  into  the  simulation  model;  the  time  required  would  be  unreasonable.  On  the 
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Figure  37.  Throughputs;  Sin^e  Addressing  Only  Stations 


Figure  38.  Throughput:  Multicast  Capable  Stations,  Single  Addressing  Mode 


Ill 


other  hand,  ahhough  the  siinulation's  execution  is  noticeably  slowed  by  the  extra  events 
generated  in  the  destination  address  assignmoit  loop,  the  throughput  rate  should  not  be 
affected  because  the  simulated  passage  of  time  is  controlled  by  the  Kemd  Procedures.  That 
is,  one  microsecond  does  not  pass  until  the  ^uladon  has  completed  one  microsecond's 
worth  of  events,  at  all  pmnts  on  the  LAN.  This  is  how  simultaneous  events  around  the  LAN 
are  conducted,  one  at  a  time.  For  example,  a  new  packet  arrival  at  station  f  7,  and  a  packet 
destruction  at  station  f  23,  and  a  token  release  at  station  f  0  may  all  occur  simultaneously.  A 
study  of  the  sequence  of  events,  revealed  throu^  use  of  the  ddmg  facility,  shows  that  the 
simulation's  clock  is  incremented  after  these  events  are  all  completed,  thereby  modeling 
simultaneous  events.  The  eight  percent  reduction  in  total  throughput  may  indicate  the 
simulation  timer  is  proceeding  without  waiting  for  the  completion  of  the  loop. 

3.  Second  test 

a.  Setup 

This  test  was  intended  to  compare  the  throu^iput  resulting  from  two  nearly 
identical  simulations,  in  which  the  first  involved  only  synchronous  traffic,  and  the  second 
involved  only  asynchronous  traffic  A  ten-station  LAN  was  created,  with  all  stations  having 
the  same  packet  arrival  rate  (750  packets/sec)  and  packet  size  (1000  bits).  As  in  the  previous 
test,  destination  addresses  were  linuted  to  one  station  per  packet.  TTRT  was  set  to  4.0  ms. 

b.  Results 

Figure  39  and  Figure  40  illustrate  the  throughputs  resulting  from  7.S  Mbps 
offered  load  of  all-syndironous  and  all-asynchronous  traffic,  respectively.  Interestingly,  both 
plots  are  identicaL  suggesting  perhaps  that  the  disparate  results  of  the  previous  test  indicate 
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Figure  39.  Synchronous  Throughput 


Figure  40.  Asynchronous  Throughput 


a  coding  error  whenever  mixed  loads  of  synchronous  and  asynchronous  traffic  nuist  be 
tracked  simultaneously.  Also  noteworthy  is  the  fact  that  the  resulting  throughput  in  both 
cases,  6.86  Mbps,  was  91.5%  of  the  offered  load.  This  is  comparable  with  the  previous  test, 
the  SS  Mbps  throughput  in  Figure  38  represents  91.7%  of  the  60.72  Mbps  offered  load. 
Again,  this  suggests  a  coordination  problem  between  the  addressing  loop  and  the  simulation's 
timekeeping  function. 

4.  Third  Test 

a.  Setup 

This  test  was  intended  to  compare  the  throughput  from  two  different 
perspectives  available.  One  resuh  was  generated  in  the  familiar  accounting  procedure 
conducted  in  the  sink  process  model,  and  tl»  other  result  used  the  Probe  Editor  to  place  a 
momtoring  probe  on  one  of  the  station  transmitter  nodes,  phy.tx.  If  the  transmissions  are 
arranged  so  that  all  traffic  passes  this  node,  then  the  result  should  be  two  identical 
throughputs. 

The  same  LAN  of  ten  multicast-enable  stations  was  used,  with  only  station 
f9  transmitting,  and  with  all  of  its  traffic  directed  to  station  f8.  In  between,  a  probe  was 
placed  on  the  transmitter  node  of  station  f  7 .  The  packet  arrival  rate  was  7500  packets/sec., 
and  the  packet  length  was  1000  bits,  giving  an  offered  load  of  7.5  Mbps,  all  of  which  was 
asynchronous,  with  the  full  range  of  prioritization  available.  TTRT  was  4.0  ms. 

b.  Results 

Figure  41  shows  a  roughly  constant  difference  of  approximately  0  .15  Mbps 
between  the  throughput  monitored  from  the  physical  transmitter  and  that  calculated  in  the 
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receiving  station's  sink  process.  The  irregular  plots  are  unusual,  since  the  emulations 
normally  show  a  smooth  steady  state  after  less  than  half  a  second.  Significantly,  both  curves 
remain  close  to  the  offered  load,  though  they  are  jagged. 

The  40  bits  per  packet  ov«-head  (created  in  the  Parameter  Editor,  where 
the  fields  "fc**,  "src.addr,"  and  "dest.addr**  are  assigned  sizes  of  8,  16  and  16  bits, 
respectively)  is  a  possible  source  of  disparity,  although  a  difference  of  0.3  Mbps  would  be 
expected  in  that  case  (7S00  x  40).  A  study  of  the  sink  process  model  shows  that  oveihead 
is  not  included  in  throughput  calculations,  while  the  probes  do  count  the  bits  in  the 
encapsulating  packet  structure.  As  before,  the  problem  requires  more  study. 

S.  Fourth  Test 
a  Setup 

A  final  test  of  the  expected  throughput  of  the  multicast>capable  model 
actually  observed  the  multicasting  facility,  or  more  exactly,  the  broadcasting  facility  of  the 
model.  Again,  a  ten  station  LAN  was  used,  with  only  one  station  transmitting,  with  TTRT 
set  to  4.0.  This  transmitter,  station  f  7,  generated  7500  packets  at  1000  bits  per  packet,  for 
a  total  offered  load  of  7.5  Mbps,  all  asynchronous.  In  addition,  each  packet  was  addressed 
to  all  nine  of  the  other  stations,  wluch  would  be  expected  to  yield  a  throughput  of  67. 5  Mbps. 
(The  throughput  statistics  are  gathered  by  comparing  timestamps  at  the  receipt  of  a  packet 
with  the  packet's  creation  time,  winch  is  carried  as  a  field  in  the  fddl.l  1c_fr  packet  format). 
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b.  Results 


Figure  42  illustrates  ^  actual  result.  The  probe  at  station  f  7's  "phy.tx" 
node  reflects  the  offered  load  of  7.S  Ml^  with  reasonable  accuracy.  However,  the  eiqiected 
throughput  of  67.5  Mbps  was  not  nearly  realized.  The  throughput  plotted,  48.9  Mbps, 
represents  72.44%  of  the  predicted  amount.  Again,  this  indicates  a  need  to  further  develop 
the  modd,  and  to  better  define  the  meanings  of  throu^qxit  and  offered  load  \diai  packets  are 
addressed  to  more  than  one  station  at  a  time. 
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Figure  41.  Througlq)ut  from  Two  Vantage  Points 


UM  (t««> 


Figure  42.  Broadcast  from  One  Station 


V.  CONCLUSIONS  AND  RECOMMENDATIONS 

A.  CONCLUSIONS 

This  thesis  has  been  directed  to  two  main  purposes:  to  esqilain  the  use  and  operation 
of  OPNET^s  FDDI  LAN  simulation,  and  to  describe  the  changes  that  were  installed  in  the 
model  in  order  to  make  h  a  more  useful,  accurate  and  versatile  tool  for  the  Common  Data 
Link  project.  Both  goals  share  another  common  olqective,  which  is  to  develop  and  document 
the  "corporate  knowledge"  of  the  CDL  working  group  which  will  continue  to  work  with  the 
model  studied  here. 

One  immechate  conclusion  is  the  observation  that  OPNET  is  a  powerful  and  flexible 
tool,  but  it  requires  much  time  and  study  to  be  used  effectively.  Where  desired  model 
attributes  are  lacking,  the  patiem  user  may  code  his  or  her  own.  The  following  are  the 
accomplishments  documemed  with  this  thesis; 

1 .  Throu^qxit,  mean  delay,  and  end-to-end  delay  data  are  recorded  separately  and 
may  be  displayed  separately  for  synchronous  packet  traffic  and  each  priority  level 
of  asynchronous  packet  traffic.  In  addition,  two  new  scalar  plot  axes, 
"Asynchronous  Offered  Load”  and  "Total  Offered  Load”  are  available  for  the 
display  of  LAN  performance  data  in  relation  to  usage. 

2.  The  FDDI  station  model  is  capable  of  randomly  choosing  different  priority 
threshoki  settii^  to  assign  to  generated  asynchronous  packets,  where  before  the 
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modd  was  bound  to  one  setting  per  simulation.  This  modification  allows  an 
additional  measure  of  flexibility  in  assigning  the  transmission  characteristics  of 
anFDDILAN. 

3.  A  rudimentary  linking  node  has  been  created,  which  accumulates  received  traffic 
in  bufiers  for  eventual  transmission  to  another  LAN. 

4.  A  multicasting  capability  has  been  added  to  the  FDDI  station  modd,  enabling 
packets  to  be  addressed  to  more  than  one  destination  station.  Prdiminary  tests 
and  studies  indicate  the  modd  correctly  generates,  transmits,  receives,  and 
diqxises  of  the  multicast  packets,  although  unexpected  throu^qnit  data  suggest 
the  modd  possibly  has  coding  inaccurades  or  in^oper  interfiicing  of  simulation 
timing  and  destination  address  generation. 

5.  A  modest  series  ofprdiminaty  tests  verifies  the  continuing  valid  operation  of  the 
modified  models,  for  the  most  part. 

6.  A  significam  lunber  of  unmq)ected  features  of  OPNEPs  FDDI  LAN  model  are 
documented,  for  the  benefit  of  those  researchers  continuing  to  work  on  the  CDL 
proje; 


B.  RECOMMENDATIONS 

Because  the  eventud  god  of  the  work  b^;un  in  this  thesis  is  the  development  of  a  large 
scde  model  simulation  for  a  Network  Interfiice,  the  development  of  the  FDDI  LAN  model 
may  be  e9q)ected  to  continue.  The  following  are  some  possible  areas  for  further  development: 
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1.  Asmentwned,  Aeimihicasringfettureykidsuiioqjcctedlykwthrou^  The 
ocxiqrioc  nature  of  the  duotges  made  to  the  code  to  enaUe  multicasting  suggests 
the  likelihood  some  lo^  cffor  or  timing  imerfiice  discrqumcy.  This  ought  to 
be  fi}und  and  conected. 

2.  The  testing  presented  in  this  thesis  is  only  preliminary,  and  could  well  be 
expanded  upon.  Because  of  time  constraints,  dday  characteristics  were  not 
addressed  at  all. 

3.  The  buffered  subqueues  ofthepreliminaiy  bridging  model  are  infinite  by  defiuih, 
but  may  be  assigned  limits  through  the  use  of  on-screen  attributes.  The  code 
currently  has  no  provision  for  the  proper  disposal  of  packets  lost  to  buffer 
overflows;  lost  flames  will  fill  tlw  host  terminal's  memory  until  none  remains.  A 
related  but  separate  issue  is  the  fiia  that  there  is  no  retransmission  protocol  in 
effect  for  the  current  modd. 
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APPENDIX  A.  FILE  RETRIEVAL  VIA  FTP 


The  following  is  an  excerpt  from  a  screen  dialogue  demonstrating  access  to  MIL  3 

Inc.'s  bulletin  board,  movement  among  subdirectories,  and  retrieval  of  files. 

sun24: /home3/n1x 
*  ftp 
ftp>  open 
(to)  m113.com 
Connected  to  m113.com. 

220  rmaxwell  FTP  server  (SunOS  4.1)  ready. 

Name  (m113.com:n1x) :  anonymous 

331  Guest  login  ok.  send  Ident  as  password. 

Password:  nixdece.nps. navy. mil 

230  Guest  login  ok.  access  restrictions  apply. 

ftp>  dir 

200  PORT  command  successful . 

150  ASCII  data  connection  for  /bln/ls  (131.120.20.124.2926)  (0  bytes), 
total  18 

'rw-r--r*-  1  0  100  2110  Jul  21  00:32  FTP. Instructions 

-r--r--r--  1  0  1  5135  Jan  21  1992  README. OPSIG 

dr-xr-xr-x  20  1  512  Jan  14  1992  bln 

dr-xr-xr-x  20  1  512  Jan  14  1992  dev 

dr-xr-xr*x  20  1  512  Jan  14  1992  etc 

drwxr-xr-x  50  1  512  Oct  27  1992  examp 

drwx-*x*-x  20  1  512  Dec  20  16:40  Incoming 

dr-xr-xr-x  10  0  1  512  Dec  23  17:34  model.depot 

drwxr-xr-x  10  0  1  512  Dec  15  10:09  patches 

drwxrwxrwx  30  1  512  Dec  29  03:05  tmp 

dr-xr-xr-x  30  1  512  Jan  14  1992  usr 

226  ASCII  Transfer  complete. 

700  bytes  received  In  3.1  seconds  (0.22  Kbytes/s) 

ftp>  get  README. OPSIG 

200  PORT  command  successful . 

150  ASCII  data  connection  for  README. OPSIG  (131.120.20.124.2927)  (5135 
bytes) . 

226  ASCII  Transfer  complete. 

local:  README. OPSIG  remote:  README. OPSIG 

5257  bytes  received  In  6.8  seconds  (0.75  Kbytes/s) 

ftp>  cd  patches 

250  CWD  command  successful . 

ftp>  dir 

200  PORT  command  successful . 

150  ASCII  data  connection  for  /b1n/1s  (131.120.20.124.2928)  (0  bytes), 
total  8 
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drwxr-xr-x  6  101  1  512  Mar  10  1993  2.3. L 

drwxr-xr-x  4  101  100  512  Apr  2  1993  2.3. Lhp 

drwxr-xr-x  6  101  1  512  Sep  24  22:42  2.3.M 

drwxr-xr-x  4  101  1  512  Dec  6  18:37  2. 4. A 

drwxr-xr-x  5  101  1  512  Dec  17  22:32  2.4.B 

drwxr-xr-x  4  101  1  512  Jan  29  1993  2.4.beta2 

drwxr-xr-x  13  101  1  512  Apr  26  1993  2.4.beta3 

drwxr-xr-x  5  101  1  512  Jun  10  1993  2.4.beta4 

226  ASCII  Transfer  complete. 

511  bytes  received  In  0.63  seconds  (0.6  Kbytes/s) 

250  CWO  command  successful . 
ftp>  cd  2.4.B 

250  CWD  command  successful . 
ftp>  dir 

200  PORT  command  successful . 

150  ASCII  data  connection  for  /bln/ls  (131.120.20.124,2934)  (0  bytes), 
total  3 

drwxr-xr-x  2  101  100  512  Dec  15  10:11  opbug_20ai 

drwxr-xr-x  20  1  512  Dec  17  22:33  tsup_3139 

drwxr-xr-x  20  1  512  Dec  17  20:15  tsup_3182 

226  ASCII  Transfer  complete. 

205  bytes  received  In  0.28  seconds  (0.7  Kbytes/ s) 

ftp>  cd  opbug_2081 

250  CWO  command  successful . 

ftp>  dir 

200  PORT  command  successful . 

150  ASCII  data  connection  for  /bln/ls  (131.120.20.124.2935)  (0  bytes), 
total  57 

-rw-r--r--  1  101  100  3988  Dec  15  07:12  README 

-rw-r--r--  1  101  100  53379  Dec  15  07:12  fdd1_raac.pr .m 

226  ASCII  Transfer  complete. 

141  bytes  received  1n  0.22  seconds  (0.62  Kbytes/s) 

ftp>  get  README 

200  PORT  command  successful . 

150  ASCII  data  connection  for  README  (131.120.20.124,2936)  (3988 
bytes) . 

226  ASCII  Transfer  complete. 

local:  README  remote:  README 

4092  bytes  received  In  5  seconds  (0.81  Kbytes/s) 

ftp>  bln 

200  Type  set  to  I. 

ftp>  get  fdd1_mac.pr.ra 

200  PORT  command  successful . 

150  ASCII  data  connection  for  fdd1_mac.pr.m  (131.120.20.124.2937) 
'(53379  bytes). 

226  ASCII  Transfer  complete, 
local:  fdd1_mac.pr .m  remote:  fdd1_mac.pr.m 
53388  bytes  received  In  64  seconds  (0.81  Kbytes/s) 
ftp>  quit 
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APPENDIX  B.  PACKET  AND  ICl  FRAME 


STRUCTURES 


The  following  packet  structures  are  used  in  the  FDDI  LAN  modd. 

A.  PACKET  FORMATS 


1. 

Field  Name  Type  Size  (bits)  Default  Value  Default  Set 


cr_t1me  double  0  0.0  set 

prl*®**  Integer  0  0  unset 


Note;  Added  to  allow  generation  of  statistics  rdated  to  prioritized  trafBc 
2.  “fddLmacJr'’ 


Field  Name 

Type 

Size  (bits) 

Default  Value 

Default  Set 

fc 

Integer 

8 

unset 

src_addr 

Integer 

16 

unset 

dest.addr 

Integer 

16 

unset 

Info 

packet 

-1 

unset 

svc_class 

Integer 

0 

unset 

prl 

Integer 

0 

unset 

tk_class 

Integer 

0 

unset 

"fddLinac^tk" 

Field  Name 

Type 

Size  (bits)  Default  Value 

Default  Set 

fc 

Integer 

8 

unset 

cl  ass 

Integer 

0 

unset 

res_stat1on 

Integer 

0 

unset 
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B.  ICI  FORMATS 


**fddi_iiuic_uid'* 

Attribute  Name 

Type 

Defaul t 

src_addr 

Integer 

0 

dest.addr 

Integer 

0 

'*fddi_iiUK!_req'* 

Attribute  Name 

Type 

Defaul t 

svc.class 

Integer 

0 

dest_addr 

Integer 

0 

pri 

Integer 

0 

tk_class 

Integer 

0 
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APPENDIX  C.  EXAMPLE  ENVIRONMENT  FILE 


FOR  32-STATION  FDDI  LAN 


#  fdd132.ef 

#  sample  simulation  configuration  file  for  fddi  example  model 

#  32  station  network 

Attributes  related  to  loading  used  by  •fdd1_gen"  *** 

station  addresses 
*.*.f0.mac.stat1on_address:  0 
*.*.fl.mac.stat1on_address:  1 
*.*.f2.mac.stat1on_address:  2 
*.*.f3.mac.stat1on_address:  3 
*.*.f4.mac.station_address:  4 
*.*.f5.mac.station_address:  5 
*.*.f6.mac.station_address:  6 
*.*.f7.mac.stat1on_address;  7 
*.*,f8,mac.stat1on_address:  8 
*,*.f9.mac.stat1on_address;  9 
*.*.fl0.mac.stat1on_address:  10 
*.*.fll .mac.station.address:  11 
*.*.fl2.mac.stat1on_address;  12 
*.*.fl3.mac.stat1on_address;  13 
*.*.fl4.mac.station_address:  14 
*.*.fl5.mac.stat1on_address:  15 
*.*.fl6,mac.station_address :  16 
*.*.fl7.mac.station_address:  17 
♦.*.fl8.mac.stat1on_address:  18 
*.*.fl9.mac.station_address:  19 
*.*.f20.mac.station_address:  20 
*.*.f21.mac.stat1on_address;  21 
*.*.f22.mac.station_address:  22 
*.*.f23.mac.stat1on_address :  23 
*.*.f24.mac.station_address :  24 
*.*.f25.mac.stat1on_address :  25 
*.*.f26.mac.stat1on_address :  26 
*.*.f27 .mac.station_address:  27 
*.*.f28.mac.station_address:  28 
*.*.f29.mac.stat1on_address:  29 
*.*.f30.mac.station_address:  30 
*.*.f31.mac.station_address:  31 
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mac. r1ng_1d  :0 


#  destination  addresses  for  random  message  generation 

’*.*.nc_src.low  dest  address"  :  0 

**.*.nc_src.h1gh  dest  address'  :  31 

#"top.ring0.f0.11c_src.low  dest  address"  : 

#"top.r1ng0.f0.11c_src.h1gh  dest  address"  : 

if  arrival  rate(frames/sec) ,  and  message  size  (bits)  for  random  message 

#  generation  at  each  station  on  the  ring. 

■*.*.*. arrival  rate"  :  200 

"*.*.*. mean  pk  length"  :  500 

#  set  the  proportion  of  asynchronous  traffic 

#  a  value  of  1.0  indicates  all  asynchronous  traffic 

**.*.*.async_m1x"  :  1.0 

#***  Ring  configuration  attributes  used  by  "fddl^mac"  *** 

if  allocate  percentage  of  synchronous  bandwidth  to  each  station 

if  this  value  should  not  exceed  1  for  all  stations  combined;  OPNET  does 

not 

if  enforce  this;  01FEB94:  this  must  be  less  than  1;  see  equation  below 

mac. sync  bandwidth*  :  0.0 

if  •♦.fO. mac. sync  bandwidth"  :  .0935487 

**.*.mac.T_Req*  :  .010 

if  Index  of  the  station  which  Initially  launches  the  token 
"spawn  station":  0 

if  Delay  incurred  by  packets  as  they  traverse  a  station's  ring  Interface 
if  see  Powers,  p.  351  for  a  discussion  of  this  (Powers  gives  lusec, 
if  but  60.0e-08  agrees  with  Dykeman  I  Bux) 
station_latency:  60.0e-08 

if  Propagation  Delay  separating  stations  on  the  ring. 
prop_delay:  5.085e-06 

if***  Simulation  related  attributes 

if  Token  Acceleration  Mechanism  enabling  flag. 

if  It  is  reccomended  that  this  mechanism  be  enabled  for  most  situations 
accelerate_token:  1 
seed:  10 

if  Run  control  attributes 
duration:  5 
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verbose_s1ro: 
upd_1 nt : 
os_f  He: 


TRUE 

.1 

fdd132mod 


ov_fne:  fdd132niod 

#  Opnet  Debugger  (odb)  enabling  attribute 

#  debug:  TRUE 
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APPENDIX  D.  DEBUG  TOOL  EXCERPT 


The  following  is  an  excerpt  from  the  ddxigger  in  fulhrace,  showing  the  arrival  and 
reception  of  a  message  traffic  packet  at  its  destination  address.  In  this  case,  station  f  1 1 
has  sent  a  packet  to  station  f31.  The  packet  has  been  passed  "hand  to  hand"  through  each 
station  in  between,  with  the  simulator  enacting  every  step  along  the  way.  Note  that  when 
reception  is  complete,  the  simulation  returns  to  station  f  1 1,  which  still  has  the  token. 


_  (ODB  2. 4. A:  Event) _ 

Time  :  0.995744186808  sec.  COOd  OOh  OOm  00s  .  995ms  744us 

186ns  608ps] 

*  Event  :  execution  10  (461704),  schedule  ID  (#502933).  type 

(self  Intrpt) 

*  Source  :  execution  ID  (461703),  top.ring0.f30.phy_tx  (pt-pt 

transmitter) 

*  Data  :  code  (0) 

>  Module  :  top. r1ng0.f30.phy_tx  (pt-pt  transmitter) 
odb>  next 


*  Kernel  Action:  Pt-Pt  Transmitter  object 
Completing  transmission  of  packet(s) 
channel  (0) 
packet  ID  (4459) 

_  (ODB  2. 4. A:  Event)  _ 

*  Time  :  0.995744186808  sec.  [OOd  OOh  OOm  00s  .  995ms  744us 

186ns  808ps] 

*  Event  :  execution  ID  (461705),  schedule  ID  (#502934),  type 

(remote  Intrpt) 

*  Source  :  execution  ID  (461703),  top. ring0.f30.phy_tx  (pt-pt 

transmitter) 

*  Data  :  code  (0) 

>  Module  :  top . rIngO .f31 .phy_rx  (pt-pt  receiver) 
odb>  next 


*  Kernel  Action:  Pt-Pt  Receiver  object 
Beginning  reception  of  packet 
channel  (0) 
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packet  ID  (4459) 

_  (ODB  2. 4. A:  Event)  _ 

*  Time  :  0.995744186808  sec.  [000  OOh  00m  00s  .  995ms  744us  186ns 

808ps] 

*  Event  execution  ID  (461706).  schedule  ID  (#502935),  type 
(remote  Intrpt) 

*  Source  :  execution  ID  (461703).  top.r1ng0.f30.phy_tx  (pt-pt 
transmitter) 

*  Data  :  code  (0) 

>  Module  :  top.r1ng0.f31.phy_rx  (pt-pt  receiver) 
odb>  next 

*  Kernel  Action:  Pt-Pt  Receiver  object 

Completing  reception  of  packet 
channel  (0) 
packet  ID  (4459) 

*  Kernel  Action:  Pt-Pt  pipeline 

Calling  (error)  pipeline  stage 
packet  ID  (4459) 

*  op_td_get_1nt  (pkptr.  tda^lndex) 

packet  ID  (4459) 

TDA  attribute'  (0PC_T0A_PT_LINK_0BJ1D) 

TDA  value  (82) 

*  op_1ma_obj_attr_get  (objid.  attr_name,  value  ptr) 

objid  (82) 

attr_name  (ber) 
value  (0.0) 

*  op_pk_total_sl2e_get  (pkptr) 

packet  ID  (4459) 
total  size  (25040) 

*  op_td_set_1nt  (pkptr.  tda_1ndex,  value) 

packet  ID  (4459) 

TDA  attribute  (0PC_TDA_PT_NUM_ERR0RS) 

TDA  value  (0  bit  errs) 

*  Kernel  Action:  Pt-Pt  pipeline 

Calling  (ecc)  pipeline  stage 
packet  ID  (4459) 

*  op_td_1s_set  (pkptr,  tda_1ndex) 

packet  ID  (4459) 

TDA  attribute  (0PC_TDA_PT_ND_FAIL) 
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tda  is  set  (false) 


*  op_td_get_1 nt  (pkptr,  tda_1ndex) 

packet  ID  (4459) 

TDA  attribute  (OPC_TDA_PT_RX_OBJID) 

TDA  value  (734) 

*  op_ima_obj_attr_get  (objid,  attr_name,  value_ptr) 

objid  (734) 

attr.name  (ecc  threshold) 

value  (0.0) 

*  op_pk_total_s1ze_get  (pkptr) 

packet  ID  (4459) 
total  size  (25040) 

*  op_td_get_1 nt  (pkptr,  tda_1ndex) 

packet  ID  (4459) 

TDA  attribute  (0PC_TDA_PT_NUM_ERR0RS) 

TDA  value  (0  bit  errs) 

*  op_td_set_1nt  (pkptr,  tda_1ndex,  value) 

packet  ID  (4459) 

TDA  attribute  (0PC_TDA_PT_PK_ACCEPT) 

TDA  value  (1) 

*  Kernel  Action:  Pt-Pt  Receiver  object 

Packet  successfully  received 
channel  (0) 
packet  ID  (4459) 

_  (ODB  2. 4. A:  Event)  _ 

*  Time  :  0.995744186808  sec,  COOd  OOh  00m  OOs  .  995ras  744us  186ns 

808ps] 

*  Event  :  execution  ID  (461707),  schedule  ID  (#502936),  type 
(stream  intrpt) 

*  Source  :  execution  ID  (461706),  top.r1ng0.f31.phy_rx  (pt-pt 
receiver) 

*  Data  :  instrm  (0),  packet  ID  (4459) 

>  Module  :  top.r1ng0.f31.mac  (queue) 

odb>  next 


*  Invoking  process  ("fdd1_mac’) 
_ state  (IDLE):  exit  executives 

*  op_1ntrpt_type  () 

Intrpt  type  (stream  Intrpt) 
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op_1ntrpt_strra  () 
active  strm  (0) 


* 


*  op_plc_get  (1nstrni_1ndex) 

strm.  Index  (0) 
packet  ID  (4459) 

*  op_pk_nfd_get  (pkptr,  fd_name,  value_ptr) 

packet  ID  (4459) 
field  name  (fc) 
value  (0) 

*  op_1ntrpt_type  () 

Intrpt  type  (stream  Intrpt) 

*  op_1ntrpt_type  () 

Intrpt  type  (stream  Intrpt) 

*  op_1ntrpt_strm  () 

active  strm  (0) 

_ state  (FR_RCV):  enter  executives _ 

*  op_pk_nfd_get  (pkptr,  fd^name,  va1ue_ptr) 

packet  ID  (4459) 
field  name  (src_addr) 
value  (11) 

_ state  (FR_RCV);  exit  executives _ 

_ state  (FR_REPEAT):  enter  executives _ 

*  op_pk_nfd_get  (pkptr.  fd_name.  value_ptr) 

packet  ID  (4459) 
field  name  (dest_addr) 
value  (31) 

*  op_pk_total_s1ze_get  (pkptr) 

packet  ID  (4459) 
total  size  (25040) 

*  op_pk_nfd_get  (pkptr,  fd_name.  value_ptr) 

packet  ID  (4459) 
field  name  (Info) 
value  (pk  Id  (4458)) 

*  op_1c1_attr_set  (Iciptr,  attr_name,  attr_value) 

ICI  Id  (81) 

attr  name  (src_addr) 
value  (11) 
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*  op_1c1_attr_set  dciptr,  attr_na«e.  attr_value) 

ICI  1d  (81) 

attr  name  (dest.addr) 
value  (31) 

*  op_1c1_1nstan  (Iciptr) 

ICI  ID  (81) 

*  op_pk_send_delayed  (pkptr.  outstrm_index.  delay) 

packet  ID  (4458) 
stream  Index  (1) 
delay  (0.0002504) 

*  op_pk_destroy  (pkptr) 

packet  ID  (4459) 

*  Kernel  Action:  Destroying  Packet 

packet  ID  (4459) 

_ state  (FR_REPEAT):  exit  executives _ 

_ state  (IDLE):  enter  executives _ 

*  returning  from  process  (•fdd1_mac*) 

_  (008  2. 4. A:  Event)  _ 

*  Time  :  0.995886571808  sec.  COOd  OOh  00m  00s  .  995ms  886us  571ns 

808ps] 

*  Event  :  execution  ID  (461708).  schedule  ID  (#502837).  type 
(stream  Intrpt) 

*  Source  :  execution  ID  (461607).  top.r1ng0.fll.mac  (queue) 

*  Data  :  Instrm  (0).  packet  ID  (4457) 

>  Module  :  top.rlngO.fll.phy^tx  (pt-pt  transmitter) 

odb>  next 
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APPENDIX  E.  MAC  "C"  CODE 


"fddi_mac_multpr.c  " 


The  line  numbering  in  this  appendbc  is  used  for  reference  within  this  thesis  only,  and 
does  not  correspond  with  that  seen  in  OPNEl^s  text  editors. 


1  I*  Process  model  C  form  file:  fdd1_mac_mult.pr.c  *! 

2  /*  Portions  of  this  file  Copyright  (C)  MIL  3,  Inc.  1992  */ 

3  /*  OPNET  system  definitions  */ 

4  ^Include  <opnet.h> 

5  ^include  ''fdd1_mac_mult.pr .h* 

6  FSM_EXT_OECS 

7  /*  Header  block  */ 

8  /*  Define  a  timer  structure  used  to  Implement  */ 

9  /*  the  TRT  and  THT  timers.  The  primitives  defined  to  */ 

10  /*  operate  on  these  timers  can  be  found  In  the  */ 

11  /*  function  block  of  this  process  model.  */ 

12  typedef  struct 

13  { 

14  Int  enabled: 

15  double  start_t1me; 

16  double  accum; 

17  double  target_accura; 

18  }  FddiT_Timer: 

19  /*  08FEB94:  define  the  number  of  stations  here.  -Nix  */ 

20  ^define  NUM.STATIONS  50 

21  /*  Declare  certain  primitives  dealing  with  timer. s  */ 

22  double  fdd1_t1mer_remaining  {); 

23  FddiT_Timer*  fddi_t1mer_create  (): 

24  double  fddi_t1mer_val ue  {); 

25  /*  Scratch  strings  for  trace  statements  *! 

26  char  strO  [512],  strl  [512]; 

27  /*  define  constants  particular  to  this  implementation  */ 

28  ^define  FDDI_MAX_STATIONS  512 
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29  /*  define  possible  values  for  the  frame  control  field  */ 

30  fdefine  FDDI_FC_FRAME  0 

31  #def1ne  FDDI_FC_TOKEN  1 

32  /*  define  possible  service  classes  for  frames  */ 

33  #def1ne  FDOI.SVC.ASYNC  0 

34  #def1ne  FDOI^SVC.SYNC  1 

35  /*  define  Input  stream  Indices  *! 

36  #def1ne  FDDI_LLC^STRM_IN  1 

37  #def1ne  F00I_PHY_STRM_IN  0 

36  /*  define  output  stream  Indices  */ 

39  #def1ne  FDDI_LLC_STRM_OUT  I 

40  #def1ne  FDDI_PHY_STRM_OUT  0 

41  /*  define  token  classes  */ 

42  #def1ne  FD0I_TK_N0NRESTRICTED  0 

43  #def1ne  FD0I_TK_RESTRICTE0  1 

44  /*  Ring  Constants  */ 

45  #def1ne  FD0I_TX_RATE  l.Oe+08 

46  #def1ne  FO0I.SA_SCAN_TIME  28.0e-08 

47  /*  Token  transmission  time:  based  on  6  symbols  plus  16  symbols  of 

48  preamble  */ 

49  #def1ne  FDDIC_T0KEN_TX_TIME  88.0e*08 

50  /*  Codes  used  to  differentiate  remote  Interrupts  */ 

51  #def1ne  FDOIC_TRT_EXPIRE  0 

52  #def1ne  FDOIC_TK_INJECT  1 

53  /*  Define  symbolic  expressions  used  on  transition  */ 

54  /*  conditions  and  In  executive  statements.  *! 

55  #def1ne  TRT.EXPIRE  (op_1ntrpt_type  ()  —  0PC_INTRPT_REM0TE  && 

56  op_1ntrpt_code  ()  —  FDDIC_TRT_EXPIRE) 

57  ^define  TK_RECEIVED  phy_arr1val  &&  frame_control  —  FDDI_FC_T0KEN 

58  ^define  RC_FRAME  phy_arr1val  &&  frame_control  —  FD0I_FC_FRAME 

59  #def1ne  FRAME.ARRIVAL  \ 

60  op_1ntrpt_type  ()  —  OPC_INTRPT_STRM  &&  \ 

61  op_intrpt_strra  ()  —  FDOI_LLC_STRM_IN 

62  #def1ne  STRIP  ray_address  “  src.addr 

63  I*  Define  the  maximum  value  for  r1ng_1d.  This  Is  the  */ 

64  /*  maximum  number  of  FODI  rings  that  can  exist  In  a  */ 

65  /*  simulation.  Note  that  If  this  number  Is  changed,  */ 
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66  /*  the  Initialization  for  fdd1_cla1m_start  below  must  */ 

67  /*  also  be  modified  accordingly.  */ 

68  #def1ne  FDOI_MAX_RING_ID  8 

69  /*  Declare  the  operative  TTRT  value  *T_0pr'  which  Is  the  final  */ 

70  /*  negotiated  value  of  TTRT.  This  value  Is  shared  by  all  stations  */ 

71  /*  on  a  ring  so  that  all  agree  on  Its  value.  */ 

72  double  fdd1_t_opr  CF00I_MAX_RIN6_I0] ; 

73  #def1ne  Fdd1_T_0pr  (fdd1_t_opr  Cr1ng_1d]) 

74  /*  This  flag  Indicates  that  the  negotiation  for  the  final  TTRT  */ 

75  /*  has  not  yet  begun.  It  Is  statically  Initialized  here,  and  */ 

76  /*  Is  reset  by  the  first  station  which  modifies  T_0pr.  */ 

77  /*  Initialize  to  1  for  all  rings.  */ 

78  int  fdd1_cla1m_start  [FOOI.MAX.RING.ID]  -  {l.l.l.l.l.l.l.D ; 

79  #def1ne  Fdd1_Cla1m_Start  (fddl_clalm_start  Cr1ng_1d]) 

80  /*  Declare  station  latency  parameters.  */ 

81  /*  These  are  true  globals.  so  they  do  not  need  to  be  arrays.  */ 

82  double  Fdd1_St_Latency ; 

83  double  Fdd1_Prop_0el ay : 

84  /*  Declare  globals  for  Token  Acceleration  Mechanism.  *! 

85  i*  Hop  delay  and  token  acceleration  are  true  globals.  */ 

86  double  Fdd1_Tk_Hop_Delay; 

87  Int  Fdd1_Tk_Accelerate  -  1; 

88  /*  These  are  actually  values  shared  by  all  nodes  on  a  ring,  */ 

89  /*  so  they  must  be  defined  as  arrays.  *! 

90  double  fdd1_tk_block_base_t1rae  CFODI_MAX_RING_ID] ; 

91  ^define  Fdd1_Tk_Block_Base_Time  (fdd1_tk_block_base_tirae  [r1ng_1d]) 

92  Int  j1_tk_block_base_stat1on  CFDDI_MAX_RING_ID] ; 

93  ^define  Fddi_Tk_Block_Base_Stdtion  (fddi_tk_block_base_stat1on 

94  [ring_1d]) 

95  int  fdd1_tk_blocked  [FDDI_MAX_RING_ID] ; 

96  ^define  Fddi_Tk_Blocked  (fdd1_tk_blocked  [r1ng_1d]) 

97  int  fdd1_num_stat1ons  CFDDI_MAX_RING_ID] : 

98  #define  Fdd1_Num_Stat1ons  (fdd1_num_stat1ons  [r1ng_1d]) 

99  int  fdd1_num_reg1stered  [FDDI_MAX_RING_ID] ; 

100  #def1ne  Fdd1_Num_Reg1stered  (fdd1_nura_reg1stered  Cring_id]) 

101  Objid  fdd1_address«tab1e  CFDDI_MAX_RING_ID][FDDI_MAX_STATIONS] ; 

102  ^define  Fdd1_Address_Table  (fdd1_address_table  [ring_1d]) 

103  /*  Below  is  part  of  the  OPBUG  2081  patch;  FB  ended  here,  before.  -Nix  */ 
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104  /*  Evtnt  handles  for  the  TRT  are  maintained  at  a  global  level  to  */ 

106  /*  allow  token  acceleration  mechanism  to  adjust  these  as  necessary  */ 

106  /*  when  blocking  and  reinjecting  the  token.  TRT.handle  simply  */ 

107  /*  represents  the  TRT  for  the  local  MAC  *! 

108  Evhandle  fdd1_trt.hand1e  [FDDI_MAX_RIM6_ID]CFDDI_MAX_STATI0NS] ; 

109  fdefine  Fdd1_Trt_Handle  (fdd1_trt_handle  Cr1ng_1d]) 

110  fdefine  TRT_handle  Fdd1_Trt_Handle  [my.address] 

111  /*  Similarly,  the  TRT  data  structure  Is  maintained  on  a  global  level.  */ 

112  FddlT_T1mer*  fddl.trt  CF0DI_MAX_Rm6_ID]  [FDDI  MAX_STATIONS] ; 

113  fdefine  Fdd1_Trt  (fddl.trt  Cr1ng_1d3) 

114  fdefine  TRT  Fddl.Trt  [my.address] 

115  /*  Registers  to  record  the  expiration  time  of  each  TRT  when  token  Is 

116  blocked.  */ 

117  double  fdd1_trt_exp_t1me  CF00I_MAX_RlN6_rD]  [FOOI_MAX_STATIONS] ; 

118  fdefine  Fdd1_Trt_Exp_T1me  (fdd1_trt_exp_t1me  Cr1ng_1d]) 

119  I*  the  'Late.Ct'  flag  Is  declared  on  a  global  level  so  that  It  can  be 

120  */ 

121  I*  set  at  the  tim  ewhere  the  token  Is  Injected  back  Into  the  ring.  */ 

122  int  fddi_late_ct  CF0DI_MAX_RING_ID]  CFODI_MAX_STATIONS] : 

123  fdefine  Fdd1_Late_Ct  (fdd1_late_ct  Cr1ng_1d3) 

124  fdefine  Late_Ct  Fdd1_Late_Ct  [my_address3 

125  /*  Convenient  macro  for  setting  TRT  for  a  given  station  and  absolute 

126  time.  */ 

127  fdefine  TRT_SET(stat1on_1d.abs_t1me)  fddl.tlmer^set  (Fddl^Trt 

128  Cstat1on_1d3.  abs^tlme  -  op_s1m_t1me( ) ) ;  Fdd1_Trt_HandTe  [stat1on_1d3 

129  -  op_1ntrpt_schedule_remote  (abs_t1me.  FDDIC_TRT_EXPIRE. 

130  Fdd1_Address_Tab1e  Cstat1on_1d3 ) ; 

131  f*  State  variable  definitions  */ 

132  typedef  struct 

133  { 


134 

FSM_SYS_STATE 

135 

int 

sv_r1ng_1d; 

136 

Fdd1T_T1mer* 

sv_THT; 

137 

double 

s  v_T_Req ; 

138 

double 

sv_T_Pr1  [83: 

139 

Objid 

sv_my_obj1d; 

140 

int 

sv_spawn_token; 

141 

int 

sv_ray_address; 

142 

Packet* 

sv_tk_pkptr; 

143 

double 

s v_sync_bandw1 dth ; 

144 

double 

sv_sync_pc; 

145 

int 

sv_restr1cted; 

146 

Int 

sv_res_peer; 

147 

i  nt 

sv_tk_reg1stered; 

148 

Ici* 

s v_to_l 1 c_1 ci_ptr ; 
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Int  sv_tk_trace_on; 

150  )  fdd1_nac_mult_state: 


151 

152 

153 

154 

155 

156 

157 

158 

159 

160 
161 
162 

163 

164 

165 

166 


#define 
#def1ne 
#def1ne 
#def1ne 
#def1ne 
^define 
jSfdefine 
^define 
#def1ne 
#def1ne 
#def1ne 
#def ine 
^define 
#def i ne 
^define 
#def 1 ne 


pr_state_ptr  ( 

r1ng_1d 

THT 

T.Req 

T_Pr1 

ray_ob j 1 d 

spawn_token 

my.address 

tk_pkptr 

sync.bandwidth 

sync_pc 

restricted 

res_peer 

tk.registered 

to_nc_1c1_ptr 

tk_trace_on 


(fdd1_mac_niult_state*)  S1mI_Mod_State_Ptr) 
pr_state_ptr->sv_r1ng_1d 
pr_state_ptr->sv_THT 
pr_state_ptr->sv_T_Req 
pr_state_ptr*>sv_T_Pr1 
pr_state_ptr •>sv_ray_ob j 1 d 
pr_state_ptr->sv_spawn_token 
pr_state_ptr->sv_my_address 
p  r_s  t  a  te_pt  r • >s  v_t  k_p  kp t  r 
pr_state_ptr->sv_sync_bandw1dth 
pr_state_ptr->sv_sync_pc 
pr_state_ptr->sv_restr1cted 
p  r_s  t a  te_pt  r  *  >  s  v_r es_pee  r 
pr_state_ptr->sv_tk_reg1stered 
pr_state_ptr->sv_to_nc_1c1_ptr 
pr_state_ptr->sv_tk_trace_on 


167  /*  Process  model  Interrupt  handling  procedure  */ 
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169 

170 

171 

172 

173 

174 

175 

176 


void 

fddi  mac_mu1t  () 

{ 

/*  Packets  and  Id’s  */ 
Packet*  mac_frarae_ptr; 

Packet*  pdu_ptr; 

Packet*  pkptr: 

Packet*  data_pkptr; 

Id*  1c1_ptr; 


177 

178 

179 

180 
181 
182 


/*  Packet  Fields  and  Attributes  */ 

Int  req_pr1 ,  svc_class,  req_tk_class; 

Int  f rarae_control ,  src_addr; 

Int  pk_len,  pr1_level; 

static 

int  *da_ptr,  dest_addr[]; 
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184 

185 

186 


/*  Token 
i  nt 
int 

double 


Related  */ 

tk_usable,  res_stat1on.  tk_class; 

current_tk_class; 

accum_sync; 


187 

/*  Timer  - 

Related  */ 

188 

double 

tx_time 

189 

double 

tht_val 

,  t1mer_reraa1n1ng,  accum_bandw1dth; 
ue: 


190  /*  Miscellaneous  */ 

191  int  1; 
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192  Int  spa«n_stat1on.  phy_arr1v«l; 

193  char  error_str1ng  [512]; 

194  Int  nuni_fraraes_sent.  num_b1ts_sent; 

196  /*  260EC93:  loop  management  variables,  used  In  RCV.TK  */ 

196  /*  and  ENCAP  states.  -Nix  *! 


197 

Int 

NUM^PRIOS: 

198 

Int 

punt: 

199 

Int 

q_check; 

200 

!*  08FEB94: 

case  management  variables,  used 

In 

FR_REPEAT. 

-Nix  */ 

201 

Int 

for_me; 

202 

Int 

count.addees : 

203 

t*  08MAR94: 

'field  holding'  variables,  used 

In 

FR_REPEAT. 

-Nix  */ 

204 

Packet* 

1nfo_ptr; 

205  FSM_ENTER  (fdd1_mac_mult) 


206  FSM_BLOCK_SWITCH 

207  { 

206  /* . *! 

209  /**  state  (INIT)  enter  executives  **! 

210  FSM_STATE_ENTER_F0RCE0  (0.  stateO_enter_exec .  'INIT') 

211  { 

212  /*  Obtain  the  station's  address  .  This  1s  an  attribute  */ 

213  /*  of  this  process.  Addressing  Is  simplified  by  */ 

214  /*  simply  using  Integers,  and  only  one  mode.  *! 

215  /*  This  mode  Is  16  bit  addressing  unless  the  */ 

216  /*  packet  format  'fdd1_mac_fr '  Is  modified.  *! 

217  ray_obj1d  -  op_1d_self( ) :  /*  29DEC93  *l 

218  op_1ma_obj_attr_get  (my_obj1d.  "statlon.address" ,  4my_address ) ; 

219  /*  Register  the  station’s  object  Id  In  a  global  table.  *! 

220  /*  This  table  Is  used  by  the  mechanism  which  Improves  */ 

221  /*  simulation  efficiency  by  'jumping  over’  Idle  periods  */ 

222  /*  rather  than  circulating  an  unusable  token.  */ 

223  fdd1_stat1on_reg1ster  (ray_address,  my_obj1d); 

224  /*  Obtain  the  station  latency  for  tokens  and  frames.  */ 

225  /*  Default  value  Is  set  at  100  nanoseconds.  */ 

226  Fdd1_St_Latency  -  lOO.Oe-09; 

227  op_1ma_s1m_attr_get  (0PC_IMA_D0UBLE,  '’station_latency'' , 

228  4Fdd1_St_Latency) ; 

229  /*  Obtain  the  propagation  delay  separating  stations.  */ 

230  /*  This  value  Is  given  In  seconds  with  default  value  3.3  microseconds. 

231  */ 

232  Fdd1_Prop_0elay  ■  3.3e-06; 
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233 

234 


op_1ma_s1ra_attr_get  (OPC_IMA_DOUBLE.  ’prop.delay’ . 
&Fdd1_Prop_De1 ay ) : 

235  /*  Derive  the  Delay  for  a  *hop*  of  a  freely  circulating  packet.  */ 

236  Fddi_Tk_Hop_Dt,iay  -  Fddi_Prop_Del ay  +  Fddi_St_Latency : 


237  /*  The  T_Pri  []  state  variable  array  supports  priority  */ 

238  I*  assignments  on  a  station  by  station  basis  by  *l 

239  I*  establishing  a  correspondence  between  integer  priority  */ 

240  /*  levels  assigned  to  frames  and  the  maximum  values  of  the*/ 

241  /*  Token  holding  timer  (THT)  which  would  allow  packets  to  be*/ 

242  /*  sent.  Eight  levels  are  supported  here,  but  this  can  easily  */ 

243  /*  be  changed  by  redimensioning  the  priority  array.  */ 

244  /*  By  default  all  levels  are  identical  here,  allowing  */ 

245  /*  any  frame  to  make  use  of  the  token,  so  that  In  fact  */ 

246  /*  priority  levels  are  not  used  In  the  default  case.  */ 

247  /*  01JAN94;  (8*1)  1s  a  quick  attempt  to  Impart  different  weighting  */ 

248  /*  scales  on  each  priority  level,  and  Is  not  necessarily  realistic. -Nix 

249  */ 

250  for  (1  -  0;  i  <  8:  1++) 

251  { 

252  T  PrICI]  -  (double)  FddUT_0pr/(8.0  -  1);  /*  01JAN94  */ 

253  /*  printfCINIT:  T_Pr1[*d]  -  Xd;  Fddi.T.Dpr  -  *d\n’,  */ 

254  /*  i.  T.PrlCi],  Fdd1_T_0pr):  */ 

255  ) 


256  /*Create  the  token  holding  timer  (THT)  used  to  restrict  the  */ 

257  /*  asynchronous  bandwidth  consumption  of  the  station  */ 

258  THT  -  fdd1_t1mer_create  (): 

259  /*  Create  the  token  rotation  timer  (TRT)  used  to  measure  the  */ 

260  /*  rotations  of  the  token,  detect  late  tokens  and  initialize  */ 

261  /*  the  THT  timer  before  asynchronous  tranmsmissions .  */ 

262  TRT  -  fddi_timer_create  (); 

263  /*  Set  the  TRT  timer  to  expire  in  one  TTRT  */ 

264  TRT_SET  (my_address.  op_sim_t1me  ()  +  Fddi_T_0pr): 

265  /*  Initialize  the  Late_Ct  variable  which  keeps  track.  */ 

266  /*  of  the  number  of  TRT  expirations.  */ 

267  Late.Ct  -  0: 

268  /*  initially  the  ring  operates  in  nonrestricted  mode  */ 

269  restricted  -  0: 


270  /*  Create  an  Interface  Control  Information  structure  */ 

271  /*  to  use  when  delivering  received  frames  to  the  LLC.  */ 
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272 

273 

t* 

274 

!* 

275 

276 

!* 

277 

/* 

278 

/* 

279 

/* 

280 

/* 

281 

282 

283 

/* 

284 

/* 

285 

/* 

286 

287 

288 

/* 

289 

/* 

290 

/* 

291 

292 

293 

294 

/* 

295 

/* 

296 

297 

298 

299 

/* 

300 

301 

/* 

302 

303 

/* 

304 

/* 

305 

!* 

306 

!* 

307 

308 

/* 

309 

/* 

to_llc_1c1_ptr  -  op_1c1_credte  ( *fdd1_nnc_1nd’ ) ; 

The  'tk^reglstered'  variable  Indicates  If  the  station  */ 
has  registered  Its  Intent  to  use  the  token. 
tk^reglstered  -  0; 


Determine  If  the  model  Is  to  make  use  of  the  token  */ 
’acceleration*  mechanism.  If  not.  every  passing  of  the  */ 
token  will  be  expllcityly  modeled,  leading  to  large  */ 
number  of  events  being  scheduled  when  the  ring  Is  Idle  */ 

(I.e.  no  stations  have  data  to  send).  */ 

op_1raa_s1m_attr_get  (OPC_IMA_INTEGER,  "accelerate.token* , 
&Fdd1_Tk_Accelerate); 

Obtain  the  synchronous  bandwidth  assigned  */ 
to  this  station.  It  is  expressed  as  a  *! 
percentage  of  TTRT.  and  then  converted  to  seconds  */ 

op_1ma_obj_attr_get  (my_obj1d.  "sync  bandwidth",  4sync_pc): 
sync_bandwidth  -  sync_pc  *  Fdd1_T_0pr; 


Only  one  station  In  the  ring  Is  selected  to  */ 
introduce  the  first  token.  Test  If  this  station  Is  It.  *! 

If  so.  set  the  ’spawn^token*  flag.  */ 

op_1ma_s1m_attr_get  (0PC_IMA_INTE6ER,  "spawn  station", 
&spawn_statlon) : 

spawn_token  •  (spawn.statlon  “  my_address); 


If  the  station  Is  to  spawn  the  token,  create  */ 
the  packet  which  represents  the  token.  */ 
if  (spawn.token) 

{ 

tk_pkptr  -  op_pk_create_fmt  ( "fdd1_mac_tk" ) : 

assign  its  frame  control  field  */ 

op_pk_nfd_sei  (tk_pkptr,  "fc",  F00I_FC_T0KEN) ; 

the  first  token  Issued  is  non*restr1cted  *! 

op_pk_nfd_set  (tk.pkptr,  "class".  FDDI_TK_N0NRESTRICTE0) 

The  transition  will  be  made  into  the  ISSU_TK  */ 
state  where  the  tk_usable  variable  is  used.  */ 

In  case  any  data  has  been  generated,  prset  */ 
this  variable  to  one.  */ 
tk_usable  -  1; 

When  sending  packets  the  variable  accum_bandwidth  1s  */ 
used  as  a  scheduling  base.  Init  this  value  to  zero.  */ 


140 


/*  This  statement  1s  required  In  case  this  is  the  spawning  */ 
/*  station,  and  the  next  state  entered  Is  ISSUE_TK  */ 
accum_bandw1dth  -  0.0: 


/**  state  (INIT)  exit  executives  **/ 

FSM_STATE_EXIT_FORCED  (0.  stateO.exI t.exec .  "INIT') 


/**  state  (INIT)  transition  processing  **/ 
FSM_INIT_C0N0  (spawn.token) 

FSM_DFLT_C0ND 
FSM..TErT_L0GIC  ("INIT") 

FSM.TRANSIT.SWITCH 

{ 

FSM_CASE_TRANSIT  (0.  2.  state2_enter_exec .  :) 
FSM_CASE_TRANSIT  (1.  1.  statel_enter_exec .  :) 


state  (IDLE)  enter  executives  **/ 

FSM_STATE_ENTER_UNF0RCE0  (1.  statel_enter_exec .  ’IDLE") 


/★*  blocking  after  enter  executives  of  unforced  state.  **/ 

FSM.EXIT  (3.fdd1_mac_mult) 

/**  state  (IDLE)  exit  executives  **/ 

FSM_STATE_EXIT_UNF0RCED  (1.  statel.exl t_exec .  "IDLE") 

{ 

/*  Determine  if  a  trace  is  activated  for  the  FDDI  model  */ 
tk_trace_on  ■  op_prg_odb_ltrace_acti ve  ("fddi_tk*): 

/*  Trap  packets  arriving  from  physical  layer  so  that  their  */ 

/*  FC  field  can  be  extracted  before  evaluating  conditions  */ 

if  (op_i ntrpt_type  ()  —  OPC_INTRPT_STRM  &&  op_intrpt_strm  ( 
!-  FDDI_LLC_STRM_IN) 

{ 

/*  Acquire  the  arriving  packet.  */ 

pkptr  -  op_pk_get  ( FDDI_PHY_STRM_IN) : 

/*  Determine  the  type  of  packet  by  extracting  */ 

/*  the  frame  control  field.  */ 

op_pk_nfd_get  (pkptr.  "fc*.  &frame_control ) ; 

/*  Physical  layer  arrival  flag  Is  set.  */ 
phy_arrival  -  1: 
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371 
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} 

else{ 

I*  The  Interrupt  Is  not  due  to  a  physical  layer  arrival.  */ 
phy^arrival  -  0; 

/*  If  the  Interrupt  Is  a  remote  Interrupt  with  specified  code.  It 
signifies  */ 

/*  the  reinsertion  of  the  token  Into  the  ring  after  an  idle  period.  This 
only  */ 

/*  occurs  if  the  token  acceleration  mechanism  is  active.  */ 

if  (op_1ntrpt_type  ()  “  OPC_INTRPT_REMOTE  &&  op_intrpt_code 
()  —  FD0IC_TK_INJECT) 

{ 

/*  create  a  new  token  */ 

tk_pkptr  -  op_pk_create_fmt  ( *fddi_mac_tk" ) ; 

/*  assign  its  frame  control  field  */ 

op_pk_nfd_set  (tk_pkptr.  ’fc".  FDDI_FC_TOKEN) ; 

/*  the  token  is  non-restricted  */ 

op_pk_nfd_set  (tk_pkptr.  ’class*.  FDDI_TI(_NONRESTRICTED) : 

/*  insert  it  into  the  ring  */ 

op.pk.send  (tk_pkptr.  FDDI_PHY_STRM  OUT); 

) 

1 

) 

/**  state  (IDLE)  transition  proce'^slng  **/ 

FSM_INIT_COND  (TK.RECEIVED) 

FSM_TEST_C0ND  (RC_FRAME) 

FSM_TEST_C0N0  (TRT.EXPIRE) 

FSM_TEST_COND  ( FRAME.ARRIVAL) 

FSM_DFLT_COND 
FSM_TEST_L0GIC  (’IDLE") 

FSM_TRANSIT_SWITCH 

{ 

FSM_CASE_TRANSIT  (0.  3.  state3_enter_exec .  :) 

FSM_CASE_TRANSIT  (1.  4.  state4_enter_exec .  :) 

FSM_CASE_TRANSIT  (2.  7.  state7_enter_exec.  : ) 

FSM_CASE_TRANSIT  (3.  8.  state8_enter_exec .  :) 

FSM_CASE_TRANSIT  (4.  1.  5tatel_enter_exec .  :) 

1 

/* . */ 

/**  state  (ISSUE_TK)  enter  executives  **/ 

FSM_STATE_ENTER_F0RCE0  (2.  stateZ  enter_exec.  "ISSUE_TK") 

{ 

/*  If  the  token  is  sent  without  having  been  used,  and  the  station  */ 
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/* 

395 

396 

/* 

397 

398 

399 

/* 

400 

!* 

401 
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404 
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407 

408 

409 

410 

411 

/* 

412 

/* 

413 

/♦ 

414 

/* 

415 

/* 

416 

/* 

417 

418 

419 

420 

421 

/** 

422 

423 

424 

425 

426 

427 

/*- 

428 

! 

429 

430 

431 

/* 

432 

/* 

433 

/* 

434 

435 

/* 

436 

437 

/* 

oppurtunity  to  block  the  token.  */ 

1f  (!tk_usable  &&  op_q_stat  (OPC_QSTAT_PKSIZE) 


0.0) 


{ 


this  procedure  will  forward  the  token  physically.  */ 

fdd1_tk_1nd1cate_no_data  (tk.pkptr,  my_address. 
accum_bandw1dth) ; 

) 

else{ 

if  (tk_trace_on  —  0PC_TRUE) 

{ 

sprintf  (strO,  "Issuing  token.  accuni_bw  (X.9f).  prop_del 
(X.9f)".  accuni_bandw1dth.  Fdd1_Prop_Delay) ; 
op_pi'g_odb_print_major  (strO,  OPC_NIL); 

} 

Send  out  the  token  packet  using  the  accumulated  */ 
consumed  bandwidth  as  a  scheduling  base.  */ 

In  the  case  of  the  initial  spawning  of  the  token  */ 
this  will  be  zero:  otherwise  this  variable  will  */ 
reflect  the  bandwidth  consumed  since  the  last  capture  */ 
of  the  usable  token.  Propagation  delay  is  also  accounted  for.  */ 
op_pk_send_del ayed  (tk_pkptr,  FDDI_PHY_STRM_OUT, 
accum_bandwidth  +  Fddi_Prop_Del ay ) ; 


FSM_STATE_EXIT_FORCED  (2.  state2_exit_exec.  "ISSUE.TK") 

T 


FSM_TRANSIT_FORCE  (1.  statel_enter_exec.  :) 


FSM_STATE_ENTER_FORCED  (3.  state3_enter_exec ,  "RCV.TK") 
{ 


tk_pkptr  -  pkptr; 


op_pk_nfd_get  (pkptr,  "class',  &tk_class): 

/*  If  the  token  is  restricted,  determine  for  which  station.  */ 
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438 

439 

440 

/* 

441 

/* 

442 

443 

444 

/* 

445 

!* 

446 

!* 

447 

448 

/* 

449 

/* 

450 

/* 

451 

/* 

452 

/* 

453 

454 

455 

456 
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458 

/* 

459 

/* 

460 

/* 

461 

462 

/* 

463 

/* 

464 

465 

466 

467 

468 

469 

470 

/* 

471 

!* 

472 

/* 

473 

474 

475 

/* 

476 

/* 

477 

478 

479 

480 

/* 

481 

/* 

482 

/* 

483 

/* 

484 

/* 

1f  (tk  class  —  FDDI_TK_RESTRICTED) 

{ 

Place  the  station  address  In  the  variable  ’res_stat1on'  */ 
which  may  factor  In  to  the  determination  of  token  usability.  */ 
op_pk_nfd_get  (tk_pkptr.  ’res.statlon' ,  &res_stat1on) : 

} 

Determine  If  the  token  Is  usable:  */ 
assume  by  default  that  It  Is  not  */ 

Subsequent  conditions  may  override  this.  */ 
tk_usable  -  0; 

The  token  can  only  be  usable  If  there  are  frames  enqueued  */ 
27DEC93:  the  entire  bank  of  subqueues  must  be  checked.  */ 
starting  at  the  highest  priority  (corresponding  to  */ 
synchronous  traffic),  and  stopping  when  a  packet  Is  */ 
found.  Then  the  loop  Is  broken.  -Nix  */ 

NUM_PRI0S  -  9; 

for  (1  -  NUM_PRI0S  -  1;  1  >  -1;  1--) 

{ 

If  (op_subq_stat  (1.  OPC_QSTAT_PKSIZE)  >  0.0) 

{ 

examine  the  attributes  of  the  packet  at  the  *! 
head  of  the  queue,  */ 

fddi_load_frame_attrs  (&dest_addr.  &svc_class.  &pri_1evel);  */ 

fdd1_load_frame_attrs  (dest.addr.  &svc_class.  &pri_level): 

If  synchronous  data  Is  queued,  the  token  is  */ 
necessarily  usable,  regardless  of  timing  conditions.  *! 
if  (svc.class  —  FDDI_SVC_SYNC) 

{ 

tk_usable  “  1; 
break; 

} 

el  se{ 

Otherwise,  if  asynchronous  data  is  queued,  it  must 
meet  several  criteria  for  the  token  to  be  usable.  */ 

The  token  is  only  usable  only  if  it  Is  early.  */ 
if  (Late_Ct  “  0) 

{ 

The  token’s  class  must  be  nonrestricted .  unless  */ 
this  station  is  involved  in  the  restricted  transfer.  */ 

If  (tk.class  -=  FDDI_TK_NONRESTRICTED  ||  res.station 
—  my_address  ||  restricted) 

{ 

Test  the  frame’s  priority  assignment  against  the  current  TRT  */ 

This  test  uses  the  priority  indirection  table  T_Pri  */ 
so  that  only  packets  whose  T_Pri  [pri_level]  exceeds  */ 
the  TRT  can  be  transmitted.  In  other  words,  by  */ 
assigning  lower  values  to  T_Pri  for  a  given  priority  */ 
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/*  level,  packets  of  that  level  will  be  further  restricted  */ 

/*  from  using  the  ring  bandwidth.  *! 

If  (T_Pr1  [pri_level]  >«•  fdd1_t1mer_value  (TRT)) 

{ 

tk_usable  -  1; 
break: 

1 

1 

) 

) 

}  /*  closes  the  *1f  (op_subq_stat  (OPC_QSTAT_PKSIZE)  >  0.0* 

statment  */ 

)/*  closes  the  ’for"  loop  */ 


498  /*  If  the  token  Is  usable,  timers  must  be  readjusted.  */ 

499  if  (tk_usable) 

500  I 

501  /*  The  timer  adjustment  depends  on  whether  the  token  is  early  or  late. 

502  */ 

503  if  (Late.Ct  —  0) 

504  { 

506  /*  Transfer  the  contents  of  TRT  into  THT.  */ 

506  fdd1_t1mer_copy  (TRT,  THT); 


507  /*  Disable  the  THT  timer.  *! 

508  fddi_t1mer_disable  (THT); 

509  /*  Reset  TRT  to  time  the  next  rotation.  */ 

510  op_ev_cance1  (TRT_handle) : 

511  TRT_SET  (my_address,  op_sim_t1me  ()  +  Fddi_T_0pr); 

512  } 

513  e1se{ 

514  /*  If  the  token  is  late,  set  the  THT  to  its  expired  */ 

515  /*  value,  and  disable  it.  This  will  prevent  any  */ 

516  /*  asynchronous  transmissions  from  occuring.  */ 

517  fdd1_t1mer_set_val ue  (THT,  Fddi_T_0pr): 

518  fddi_timer_disable  (THT); 


519  /*  clear  the  Late  token  counter  (note  that  TRT  is  not  modified.  */ 

520  /*  so  that  less  than  a  full  TTRT  remains  before  TRT  expires  again.  *! 

521  Late_Ct  -  0; 

522  ) 

523  } 


524  /*  If  the  token  is  not  usable,  different  adjustments  are  made.  */ 

525  else! 

526  /*  Again,  the  adjustments  depend  on  the  lateness  of  the  token  */ 

527  if  (Late.Ct  --  0) 

528  { 
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/*  If  the  token  Is  not  late,  the  TRT  Is  reset  to  time  the  next  rotation 
*/ 

op_ev_cancel  (TRT_handle) ; 

TRT_SET  (roy.address,  op_s1m_t1rae  ()  +  Fdd1_T_0pr): 

) 

e1se{ 

/*  clear  the  Late  token  counter  (note  that  TRT  Is  not  modified,  *! 

/*  so  that  less  than  a  full  TTRT  remains  before  TRT  expires  again.  */ 
Late_Ct  -  0: 

1 

/*  also,  account  for  the  time  needed  by  the  token  */ 

/*  to  traverse  the  station,  since  it  is  about  to  be  sent.  *•! 

/*  Note:  station  latency  is  not  inclusive  of  token  *! 

/*  transmission  time,  but  only  of  the  time  required  to  */ 

!*’  process  and  repeat  the  token’s  symbols.  */ 

accum_bandwidth  -  Fddi_St_Latency : 


} 

/**  state  (RCV_TK)  exit  executives  **/ 

FSM_STATE_EXIT_FORCED  (3.  state3_exit_exec.  ’RCV.TK-) 
{ 

1 

/**  state  (RCV_TK)  transition  processing  **! 

FSM_INIT_C0ND  (tk.usable) 

FSM.OFLT.CONO 
FSM_TEST_L0GIC  CRCV.Tk*) 

FSM_TRANSIT_SWITCH 

{ 

FSM_CASE_TRansIT  (0.  9.  state9_enter_exec,  :) 
FSM_CASE_TRANSIT  (1,  2.  state2_enter_exec,  ; ) 


/* 


*/ 


/**  state  (FR_RCV)  enter  executives  **/ 

FSM_STATE_ENTER_F0RCE0  (4.  state4_enter_exec .  "FR_RCV*) 

{ 

/*  A  frame  has  been  received  from  the  physical  layer.  Note  that  */ 
/*  at  this  time,  only  the  leading  edge  of  the  frame  has  arrived.  */ 

566  /*  Extract  the  frame’s  source  address  (this  will  be  used  to  */ 

567  /*  determine  whether  or  not  to  strip  the  frame  from  the  ring).  */ 

568  op_pk_nfd_get  (pkptr.  ''src_addr'' ,  4src_addr): 

569  ) 

570  /**  state  (FR_RCV)  exit  executives  **/ 

571  FSM_STATE_EXIT_FORCED  (4.  state4_exi t_exec .  "FR.RCV”) 
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572  { 

573  ) 

574  /**  state  (FR_RCV)  transition  processing  **/ 

575  FSM_INIT_COND  (STRIP) 

576  FSM_DFLT_COND 

577  FSM_TEST_LOGIC  {‘FR.RCV) 

578  FSM_TRANSIT_SWITCH 

579  { 

580  FSM_CASE_TRANSIT  (0.  5.  state5_enter_exec .  ;) 

581  FSM_CASE_TRANSIT  (1.  6.  state6_enter_exec.  ;) 

582  ) 

583  /* . */ 

584  /**  state  (FR_STRIP)  enter  executives  **/ 

585  FSM_STATE_ENTER_FORCED  (5.  state5_enter_exec.  ’FR.STRIP') 

586  ( 

587  /*  Destroy  the  frame  which  has  now  circulated  the  entire  ring.  */ 

588  op_pk_destroy  (pkptr): 

589  } 

590  /**  state  (FR_STRIP)  exit  executives  **! 

591  FSM_STATE_EXIT_FORCED  (5.  State5_ex1 t.exec .  *FR_STRIP*) 

592  T 

593  } 


594  !**  state  (FR.STRIP)  transition  processing  **/ 


595  FSM_TRANSIT_FORCE  (1.  statel_enter_exec.  ;) 

596  /* . */ 


597  /**  state  (FR_REPEAT)  enter  executives  **/ 

598  FSM_STATE_ENTER_FORCED  (6.  state6_enter_exec .  "FR.REPEAT’) 

599  { 

600  /*  Extract  the  destination  address  of  the  frame.  */ 

601  /*  20FEB94;  use  a  pointer  to  the  array  dest_addr,  */ 

602  /*  since  referring  to  dest_addr  directly  produces  */ 

603  /*  unexpected  results.  -Nix  */ 

604  op_pk_nfd_get  (pkptr.  *dest_addr",  &da_ptr): 

0Qg  j  j 

606  /*  printf  ( ’'*da_ptr:  Xd:  da_ptr:  Xd;  &da_ptr:  Xd\n",  *da_ptr,  da_ptr. 

607  &da_ptr);  */ 

ggg  ^★★♦♦♦♦★★♦★★★♦★************'*'**************Hr*******llr****** ! 

609 

610  for  (i  -  0:  1  <  NUM_STATI0NS+1 ;  1++); 

611  dest_addr[i]  -  da_ptrC1]; 

612 

0*12  /  ★★★★'^★★'^★★★*'*'**'*****'***'*"**^'*"*'***’****'*"*’**'***'*r*’*'**'***'*'*'**  f 

614  /*  02MAR94:  print  out  the  address,  and  the  contents.  */ 
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615  /*  for  (1  -  0;  1  <  NUM_STATI0NS+1 ;  1-h-)  */ 

616  /*  {  *! 

617  /*  printf(’l.FR_REPEAT: element:  *d.  address:  *X/*d.  content:  Xd\n*. 

618  */ 

/*  i,  &(dest_addr[1 ] ) .  &(dest_addrCi ] ) .  dest.addrCI ] ) :*/ 

/*  }  */ 

j  **★★*♦*★*★*★*★★★**★*♦★★★*****★*★*★★*'*★♦★*•★****■*■****•★***★  ! 


/*  08FEB94:  re-1n1t1al1ze  counters.  -Nix  */ 
for_me  -  0: 
count_addees  -  0: 

/*  08FEB94:  Inspect  the  address  field:  interested  in  */ 

/*  whether  this  packet  is  sent  here  only,  or  here  and  */ 

/*  to  others,  or  to  others  only. Note  that  a  real  packet  *! 

/*  would  carry  all  the  addresses:  the  simulation  refers  */ 

/*  to  memory  locations.  -Nix  *! 

for  (i  -  1:  1  <  NUM_STATI0NS-*-l:  i-n-) 

{ 

if  (dest_addr[1 ]  —  1) 
count_addees  -h-  i: 

) 

/*  If  the  frame  is  for  this  station,  make  a  copy  */ 

/*  of  the  frame’s  data  field  and  forward  it  to  */ 

/*  the  higher  layer.  */ 

/*  if  (dest.addr  —  my_address)  */ 

/*  08FEB94:  if  this  packet  is  addressed  only  to  this  *! 

I*  station,  make  a  copy  of  the  frame’s  data  field  and  */ 

/*  and  forward  it  to  the  higher  layer.  -Nix  */ 

/*  (a)  If  the  packet  is  addressed  to  me  only...  */ 

/*  (note  offset  applied)  *f 

if  (dest_addrCmy_address^l3  ••  I  &&  count_addees  —  1) 
I 

fir  •  f 

/♦  printf("Here  is  Case  l,\n*): 

j  ★  *  / 

/*  record  total  size  of  the  frame  (including  data)  *! 

pk_len  «  op_pk_total_size_get  (pkptr); 

/*  decapsulate  the  data  contents  of  the  frame  */ 

/*  290AN94:  a  new  field,  "pri*.  has  been  added  to  */ 

/*  the  fddi_llc_fr  packet  format  in  the  Parameters  */ 

/*  Editor,  so  that  output  statistics  can  be  */ 

/*  generated  by  class  and  priority.  -Nix  ♦/ 

op_pk_nfd_get  (pkptr,  ‘info*.  &data_pkptr ) : 
op_pk_nfd_get  (pkptr.  ’’pri”,  &pri_level ) ; 
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668  /*  The  source  and  destination  address  are  placed  In  the  */ 

659  /*  LLC's  ICI  before  delivering  the  frame's  contents.  */ 

660  op_1c1_attr_set  (to_llc_1c1_ptr.  *src_addr*.  src_addr): 

661  op_1c1_attr_set  (to_llc_1c1_ptr.  'dest.addr" .  da_ptr): 

662  op_1c1_1nstall  (to_l lc_ici_ptr ) ; 

663  /*  18FEB94:  print  out  the  address,  and  the  contents. 

664  for  (1  -  0:  1  <  NUM_STATI0NS+1 :  1++) 

665  { 

666  dest_addr[1]  -  da_ptrCi]: 

666  I*  pr1ntf( "2. FR_REPEAT: element:  Xd,  address:  XX/Xd.  content:  Xd\n'.  */ 
6®  /*  1 .  4(dest_addr[1]).  &(dest_addr|;i]).  dest_addr[1  ] ) ;  */ 

670  /  ****^^^********^*************************'^******^******^*********^*  / 

671  1 

672  I*  Because,  as  noted  1n  the  FR_RCV  state,  only  the  */ 

673  /*  frame's  leading  edge  has  arrived  at  this  time,  the  */ 

674  /*  complete  frame  can  only  be  delivered  to  the  higher  */ 

675  /*  layer  after  the  frame's  transmission  delay  has  elapsed.  */ 

676  /*  (since  decapsulation  of  the  frame  data  contents  has  occured,  */ 

677  /*  the  original  MAC  frame  length  is  used  to  calculate  delay)  */ 

678  tx_time  -  (double)  pk_len  /  F0DI_TX_RATE; 

679  op_pk_send_delayed  (data_pkptr,  FDDI_LLC_STRM_OUT,  tx_time) 

680  Note  that  the  standard  specifies  that  the  original  */ 

681  /*  frame  should  be  passed  along  until  the  originating  station  */ 

682  /*  receives  It,  at  which  point  It  Is  stripped  from  the  ring.  */ 

683  /*  However,  in  the  simulation  model,  there  Is  no  Interest  */ 

684  /*  In  letting  the  frame  continue  past  Its  destination  unless  */ 

685  /*  group  addresses  are  used,  so  that  the  same  frame  could  be  */ 

686  /*  destined  for  several  stations.  Here  the  frame  is  stripped  * 

687  /*  for  efficiency  as  It  reaches  the  destination:  If  the  model 

688  I*  is  modified  to  include  group  addresses,  this  should  be  change.  •/ 

689  /*  so  that  the  frame  Is  copied  and  the  original  repeated.  */ 

690  /*  Logic  is  already  present  for  stripping  the  frame  at  the  origin.  */ 

691  op_pk_destroy  (pkptr); 

692  ) 

693  /*  08FEB94:  (b)...or  If  this  packet  is  not  for  me  at  all...  -Nix  */ 

694  else  If  (dest_addr[my_address+l]  —  0) 

695  { 

090  /★  *******************************  */ 

697  /*  printf ( 'Here  is  Case  Z.Xn");  */ 

698  /*  *■/ 

699  I*  Repeat  the  original  frame  on  the  ring  and  account  for  */ 

700  /*  the  latency  through  the  station  and  the  propagation  delay  */ 
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/*  for  a  single  hop.  */ 

/*  (Only  the  originating  stat.o**  can  strip  the  frame).  */ 
op_pk_send_del  ayeo  \  .‘Icptr,  FDDI_PHY_STRM_OUT. 
Fdd1_St_Latency  Fdd1_Prop_Delay ) : 

} 

/*  08FEB94:  (c)...or  1f  this  packet  is  for  me  and  for  others,  will  */ 
/*  need  to  send  the  contents  to  the  SINK,  then  re-encapsulate  the  */ 
/*  packet  for  further  transmission.  Much  of  this  code  Is  *! 

/*  duplicated  from  the  above.  -Nix  *! 

else  If  (dest_addr[my_address+l]  —  1  44  count_addees  >  1) 

{ 

jit  ★/ 

/*  prIntfCHere  Is  Case  3.\n*);  */ 

j-k  ***★*★*★**★★**★***♦*★★*★*★★*  */ 

I*  record  total  size  of  the  frame  (Including  data)  */ 
pk_len  -  op_pk_total_si2e_get  (pkptr): 

/*  decapsulate  the  data  contents  of  the  frame  */ 

op_pk_nfd_get  (pkptr,  'Info",  4data_pkptr ) ; 
op_pk_nfd_get  (pkptr,  “pri*,  4pr1_level); 

/ *  **♦*★***♦*★*★*★★**★★**★**★*★♦****★*★*★★★★♦♦*★★★★★*♦***♦★*★★★★★★#★  * ! 
I*  Print  out  the  address  of  the  'Info*  field  Information  */ 

/*  prIntfCCase  3:  'info'  Is  located  at  address  XXVn",  4data_pkptr) ;  */ 

I  *  **★**♦★■**♦♦*★**★*♦*★★★******♦♦**♦**★♦♦**★*♦**★*★#*★*****♦★**♦****  It  j 

/*  08MAR94:  copy  the  "Info*  address  Into  a  local  variable,  so  that  */ 
I*  1t  may  be  held  for  re-installation.  -Nix  */ 

tnfo_ptr  -  op_pk_copy(data_pkptr ) ; 


/*  The  source  and  destination  address  are  placed  In  the  */ 

/♦  LLC's  ICI  before  delivering  the  frame's  contents.  *! 

op_ic1_attr_set  (to_llc_ic1_ptr ,  ’src_addr'' ,  src_addr): 
op_ic1_attr_set  (to_llc_1ci_ptr ,  ’’dest.addr’’ ,  dest_addr): 
op_1ci_instal 1  (to_llc_1c1_ptr) ; 

/*  Because,  as  noted  1n  the  FR_RCV  state,  only  the  */ 

/*  frame's  leading  edge  has  arrived  at  this  time,  the  */ 

I*  complete  frame  can  only  be  delivered  to  the  higher  */ 

I*  layer  after  the  frame's  transmission  delay  has  elapsed.  */ 

/*  (since  decapsulation  of  the  frame  data  contents  has  occured.  */ 

/*  the  original  MAC  frame  length  is  used  to  calculate  delay)  */ 

738  tx_t1me  ■  (double)  pk_len  /  FODI_TX_RATE; 

739  op_pk_send_del ayed  (data.pkpt-,  FODI_LLC_STRM_OUT.  tx_time): 
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/■*  08FEB94:  remove  this  station  from  the  dest_addr  array,  reassemble  */ 
/*  the  packet,  and  send  the  packet  on  its  way.  -Nix  */ 
dest_addr[my_address-t-l]  ■  0; 
op_pk_nfd_set(pkptr . ‘src.addr* .  src_addr) : 
op_pk_nfd_set(pkptr . "dest.addr* .  dest_addr ) ; 
op_pk_nfd_set(pkptr. “pri • ,  pri_1eve1 ) : 
op_pk_nfd_set(pkptr . "info* .  info_ptr ) : 
op_pk_send_del ayed  (pkptr.  FDDI_PHY_STRM_OUT. 

Fdd1_St_Latency  +  Fdd1_Prop_De1ay) ; 

) 

} 

/**  state  (FR_REPEAT)  exit  executives  **l 

FSM.STATE  EXIT_FORCED  (6.  state6_exi t.exec .  ‘FR.REPEAT") 

{ 

} 

/**  state  {FR_REPEAT)  transition  processing  **/ 

FSM_TRANSIT_F0RCE  (1.  statel_enter_exec.  :) 

/* . */ 


/**  state  (TRT_EXP)  enter  executives  **! 

FSM  STATE  ENTER.FORCEO  (7.  state7_enter_exec .  ’TRT  EXP*) 

{ 

/*  The  timer  is  reset  and  allowed  to  continue  running.  */ 
TRT.SET  (my_address.  op_sim_t1me  ()  +  Fddi_T_0pr): 

/*  The  late  token  counter  is  incremented.  This  will  *! 

/*  prevent  this  station  from  making  any  asynchronous  */ 

/*  transmissions  when  it  next  captures  the  token.  */ 
Late_Ct-H-; 


/**  state  (TRT_EXP)  exit  executives  **/ 

FSM_STATE_EXIT_F0RCED  (7.  state7_exit_exec.  "TRT_EXP") 
{ 

} 

/**  state  (TRT_EXP)  transition  processing  **/ 

FSM_TRANSIT_F0RCE  (1.  statel_enter_exec .  ;) 

/* . */ 


775  /*♦  state  (ENCAP)  enter  executives  **/ 

776  FSM_STATE_ENTER_FORCED  (8.  state8_enter_exec .  "ENCAP") 

777  { 

778  /*  A  frame  has  arrived  from  a  higher  layer;  place  it  in  ■pdu_ptr’.  */ 

779  pdu_ptr  -  op_pk_get  (op_intrpt_strm  ()): 


151 


7B0  /*  Also  get  the  interface  control  information  */ 

781  /*  associated  with  the  new  frame.  */ 

782  ici_ptr  -  op_i ntrpt_ici  (): 

783  if  (ici.ptr  —  0PC_NIL) 

784  { 

785  sprintf  (error_string.  ‘Simulation  aborted;  error  in  object 

786  (Xd)‘.  op_id_self  ()): 

787  op_sim_end  (error_str1ng.  *fddi_mac:  required  ICI  not 

788  received*.  *  *,  “  *): 

789  ) 


790  /*  Extract  the  requested  service  class  */ 

791  /*  (e.g.  synchronous  or  asynchronous).  */ 

792  if  (op_1ci_attr_ex1sts  (1ci_ptr.  ■svc_class* ) ) 

793  op_ici_attr_get  (ici_ptr.  *svc_class‘.  isvc_class): 

794  else  svc_class  -  FDDI_SVC_ASYNC; 


795 

796 

797 

798 

799 

800 


/*  for  (i-0:  i<NUM_STATIONS+l ;  i-t-+)  */ 

/*  printf ( "ENCAP  a.Field:Xd.  Address(dec/hex) :Xd/XX .  Contents :Xd\n" . 
*/ 

/*  i.  gi(dest_addr[1] ) .  &(dest_addr[i  ] ) .  dest_addr[i  ] ) ;  *! 


801  /*  Extract  the  destination  address.  */ 

802  /*  20FEB94:  use  a  pointer  to  the  array,  since  the  */ 

803  /*  use  of  dest_array  as  its  own  pointer  causes  *! 

804  /*  unexpected  results.  -Nix  */ 

805  op_ici_attr_get  {ici_ptr.  *dest_addr*.  &da_ptr): 

807  /*  printf ( "&da_ptr:  Xd/XX:  da_ptr;  Xd\n\n".  &da_ptr,  &da_ptr.  da_ptr); 

808  */ 

809  /*  for  (i-0:  i<NUM_STATIONS+l :  i++)  */ 

810  /*  printf(’Xd:  &da_ptr:  Xd/XX;  da_ptr;  Xd\n\n*.  i.  &da_ptr.  ida.ptr. 

811  da_ptr): 

0-^2  /  ^'ic^ic’k’k'kie'kirif'k'kir'k'k'kif'k'k'k'kif-kir’k’k'k'k'k'k'ie’k'ie-itit'k’kic'k-it'k'k'k'kif'iKit'k-k'k'ie'if'k'kie'k'k'k’kit'k’kit'k-k'k'k'k  j 


813  for  (1-0:  i  <NUM_STATI0NS+1 :  i-t-f-) 

814  { 

815  dest_addrCi]  -  da_ptr[i]; 

816  > 

j  j 

818  /*  for  (i-0;  i <NUM_STATI0NS+1 ;  i-M-)  */ 

819  /*  printf("ENCAP  b.Field:Xd.  Address(dec/hex) :Xd/XX .  Contents :Xd\n” , 

820  */ 

821  /*  i,  &(dest_addr[i ] ) .  &(dest_addr[i ] ) .  dest_addr[i ] ) ;  */ 
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823  /*  If  the  frame  is  asynchronous,  the  priority  and  *! 

/*  requested  token  class  parameter  may  be  specified.  */ 
if  (svc.class  —  FDDI_SVC_ASYNC) 

{ 

/*  Extract  the  requested  priority  level.  */ 

if  (op_ici_attr_exists  (ici_ptr.  "pri")) 

op_ici_attr_get  (ici_ptr.  'pri*.  4req_pri): 
else  req_pri  -  0: 

/*  Extract  the  token  class  (restrictred  or  non- restri cted ) .  */ 
if  (op_ici_attr_exists  (ici_ptr,  ■tk_class’)) 

op_1c1_attr_get  (ici_ptr.  ’tk_class*.  &req_tk_cl ass ) ; 
else  req_tk_class  -  FDDI_TK_NONRESTRICTED: 

) 


/*  Compose  a  mac  frame  from  all  these  elements. 

mac_frame_ptr  -  op_pk_create_fmt  ( ■fddi_mac_fr‘ ) : 
op_pk_nfd_set  (mac_frame_ptr ,  •svc_class*.  svc_class): 
op_pk_nfd_set  (mac_f rame_ptr.  *dest_addr“.  dest_addr): 
op_pk_nfd_set  (mac_f rame_ptr.  *src_addr“,  my_address): 
op_pk_nfd_set  (mac.f rame_ptr ,  *info’,  pdu_ptr); 

if  (svc.class  —  FDOI.SVC.ASYNC) 

{ 

op_pk_nfd_set  (mac_frame_ptr.  ’tk.class",  req_tk_class) : 
op_pk  nfd_set  (mac_frame_ptr,  *pri*,  req_pri): 

) 

/*  04JAN94:  if  the  frame  is  synchronous,  assign  it  a  separate  */ 

/*  priority  so  that  it  may  be  assigned  its  own  subqueue,  and  */ 

/*  thereby  be  assigned  its  own  probe  for  monitoring.  -Nix  */ 
if  (svc.class  —  F00I_SVC_SYNC) 

{ 

op_pk_nfd_set  {mac_frame_ptr ,  "pri*.  8): 

) 

/*  Assign  the  frame  control  field,  which  in  the  model  */ 

/*  is  used  to  distinguish  between  tokens  and  ordinary  */ 

/*  frames  on  the  ring.  */ 

op_pk_nfd_set  (mac_frame_ptr .  "fc".  FDDI_FC_FRAME) : 

/*  Enqueue  the  frame  at  the  tail  of  the  queue.  */ 

/*  27DEC93:  at  the  tail  of  the  prioritized  queue.  */ 

/*  04JAN94:  must  distinguish  between  synch  &  asynch.  */ 
if  (svc.class  --  FDDI_SVC_ASYNC) 

{ 

op_subq_pk_insert  (req_pri.  mac_f rame_ptr ,  0PC_QP0S_TAIL) : 
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899 

/*  : 
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/*  : 
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/*  1 

904 

/*  ■ 

905 

906 

/*  1 

) 

if  (svc.class  —  FDDI_SVC_SYNC) 

{ 

op_subq_pk_i nsert  (8.  mac_frame_ptr ,  OPC_QPOS_TAIL) : 


if  ( !tk_registered) 

{ 

fddi_tk_regi ster  (): 
tk_regi stered  -  1: 

) 


FSM_STATE_EXIT_FORCED  (8.  state8_exi t.exec .  ’ENCAP') 
{ 

) 


FSM_TRANSIT_FORCE  (1.  statel_enter_exec .  :) 


state  (TX  DATA)  enter  executives  **/ 

FSM_STATE_ENTER_FORCEO  (9.  state9_enter_s^ec .  ’TX.OATA*) 

( 

In  this  state,  frames  are  transmitted  until  the  */ 
token  is  no  longer  usable.  Frames  are  taken  from  */ 
the  single  input  queue  in  FIFO  order.  */ 

Reset  the  accumulator  used  to  keep  track  of  bandwidth  */ 
consumed  by  the  transmissions.  Because  all  the  transmissions  */ 
are  scheduled  to  happen  at  the  appropriate  times,  but  *! 
these  schedulings  occur  instantly,  tnis  accumulator  serves  */ 
as  the  scheduling  base  for  the  transmissions.  */ 

In  other  words,  each  successively  transmitted  frame  */ 
is  delayed  relative  to  the  previous  one  by  the  time  which  */ 
the  latter  took  to  send.  At  the  end  of  transmission  (e.g,  *! 
when  the  token  is  no  longer  usable),  this  accumulator  *! 
serves  to  delay  the  forwarding  of  the  token.  */ 
accum_bandwidth  -  0.0: 

Note  that,  because  all  tranmsmissions  are  *! 
scheduled,  the  value  of  the  THT  timer  will  not  progress  */ 
between  shcedulings  (these  all  happen  in  zero  time),  and  so  */ 
the  variable  ’tht_value’  is  used  to  emulate  the  timer’s  progress. 
tht_value  »  fddi_timer_value  (THT); 

Reset  an  accumulator  which  reflects  the  consumed  */ 
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950 

/* 

synchronous  bandwidth.  */ 
accutn_sync  -  0.0: 

Reset  counters  for  transmitted  frames  and  bits.  */ 
nutp_f rames_sent  -  0: 
num_bi ts_sent  -  0: 

The  transmission  sequence  must  end  if  the  input  queue  */ 
becomes  exhausted.  Other  termination  conditions  are  */ 
embedded  in  the  loop.  */ 

27DEC93:  modify  the  loop  to  accomodate  subqueue  structure.  */ 

A  "for"  loop  is  imposed  over  the  original  "while"  loop.  */ 
First,  reset  the  break  marker,  "punt".  -Nix  */ 
punt  «  0: 

for  (i  -  NUM.PRIOS  -  1:  1  >  -1:  i--) 

( 

while  ( op_subq_stat  ( i .0PC_QSTAT_PKSIZE)  >  0.0) 

( 

Remove  the  next  frame  for  transmission.  */ 

pkptr  -  op_subq_pk_remove  (i.  0PC_QP0S_HEAD) : 

Obtain  the  frame's  service  class.  */ 

op_pk_nfd_get  (pkptr.  "svc_class*.  &svc_class): 

Synchronous  and  asynchronous  frames  are  treated  differently.  */ 
if  (svc.class  —  FDDI.SVC.SYNC) 

{ 

Obtain  the  frame's  length,  and  compute  */ 
the  time  required  to  transmit  it.  */ 

pk_len  -  op_pk_total_size_get  (pkptr): 
tx_time  »  (double)  pk_len  /  FDDI_TX_RATE : 

C'.ick  if  synchronous  bandwidth  allocation  for  this  */ 
station  would  be  exceeded  if  the  transmission  were  to  occur.  *! 
if  (accum_sync  +  tx_t1me  >  sync_bandwi dth ) 

{ 

The  frame  could  not  be  sent  without  exceeding  */ 
the  allocated  synchronous  bandwidth.  */ 
so  it  is  replaced  on  the  queue.  */ 

27DEC93:  in  this  case,  i  is  the  hignest  priority,  */ 
which  is  reserved  for  synchronous  traffic.  -Nix  */ 

op_subq_pk_i nsert  (i.  pkptr.  0PC_0P0S_HEAD ) : 

Exit  the  transmission  loop  since  the  frame  */ 
transmission  request  cannot  be  honored.  */ 
punt  =  1: 
break: 

} 

el  se{ 

Send  the  frame  into  the  ring  after  other  frames  have  completed. 


*/ 
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951 

/* 

952 

963 

/* 

954 

/* 

955 

956 

/* 

957 

958 

/* 

959 

960 

961 

/* 

962 

/* 

963 

964 

965 

/* 

966 

967 

968 

969 

970 

971 

/* 

972 

/* 

973 

/* 

974 

975 

976 

/* 

977 

978 

979 

980 

981 

982 

/* 

983 

984 

/* 

985 

!* 

986 

/* 

987 

/* 

988 

/* 

989 

/* 

990 

/* 

991 

/* 

992 

993 

994 

995 

Also,  account  for  its  proagation  delay;  because  the  token  propagation 
*/ 

delay  and  the  frame  propagation  delay  must  be  consistent,  and  the  */ 
token  propagation  delay  is  specified  as  a  ring  parameter  (i.e. 
stations  */ 

are  assumed  to  be  equaVy  spaced),  the  ring  is  intended  to  run  with 
*/ 

the  "delay"  attributes  of  point-to-point  links  set  at  zero.  */ 
op_pk_send_del ayed  (pkptr.  FDDI_PHY_STRM_OUT. 
accum_bandwidth  +  Fddi_Prop_Del ay ) ; 

increase  the  consumed  bandwidth  to  reflect  this  */ 
transmission.  Also  increase  synchronous  consumption.  */ 
accum_bandwi dth  +=  tx_time: 
accum_sync  -*■=  tx_time: 

Increase  counters  for  transmitted  bits  and  frames.  */ 

num_frames_sent+-t-; 

num_bi  ts_sent  -t—  pk_len: 

} 


el  se{ 

The  request  enqueued  at  the  head  of  the  queue  is  */ 
asynchronous.  It  may  only  be  honored  if  the  THT  timer  */ 
has  not  expired.  */ 

if  (tht_value  >=  Fddi_T_0pr) 

I 

replace  the  packet  on  the  queue  and  exit  the  transmission  loop.  */ 
op_subq_pk_insert  (i,  pkptr.  0PC_QP0S_HEAD) : 
punt  -  1 : 
break: 

) 

el  se{ 

Obtain  the  priority  assignment  of  the  frame.  */ 

op_pk_nfd_get  (pkptr,  "pri",  &pri_level ) ; 

If  the  packet’s  assigned  priority  level  */ 

is  too  low  for  it  to  be  serviced,  then  exit  the  loop  */ 

after  replacing  the  packet  in  the  queue.  *> 

★  j 

08MAR94:  print  the  values  to  be  compared.  -Nix  */ 
printf("l.  TX_DATA:  T_PriC*d]  <  tht_value  ?\n".  i);  */ 
printf("%d  <  *d  ?\n".  T_Pri  [i],  tht_value):  */ 

★  ★★★■*■★*★★**★★*'★★★★**★★★★★*★★★**★*■*■*■*”**★★★★*★***★'*’★*  ★  f 

if  (T_Pri  [pri_level]  <  tht_value) 

{ 

op_subq_pk_insert  (i,  pkptr,  0PC_QP0S_HEAD) : 
punt  =  1: 
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break: 


/*  Obtain  the  frame’s  length,  and  compute  the  time  */ 

/*  which  would  be  required  to  transmit  it.  */ 

pk_1en  -  op_pk_tota1_si2e_get  (pkptr): 
tx_time  ■  (double)  pk_1en  /  FDDI_TX_RATE : 

/*  Determine  the  requested  token  class  to  be  */ 

/*  released  after  this  frame  is  transmitted.  */ 

op_pk_nfd_get  (pkptr.  *tk_class’.  itk_class): 

/*  If  the  station  is  in  restricted  mode,  then  it  may  */ 

/*  exit  this  mode  if  the  class  is  now  nonrestricted  */ 

/*  or  if  the  restricted  peer  is  not  the  addressee.  */ 

if  (restricted) 

{ 

/*  Determine  the  destination  address  for  the  new  packet.  */ 

op_pk_nfd_get  (pkptr,  “dest_addr".  dest_addr): 

/*  if  (tk.class  --  FDDI_TK_NONRESTRICTED  ||  */ 

/*  res_peer  !-  dest_addr)  */ 

if  (tk_class  —  FDDI_TK_N0NRESTRICTED  || 
dest_addr[res_peer3  !-  1) 

( 

/*  Exit  restricted  mode  */ 

restricted  -  0: 

/*  Modify  the  token  to  reflect  the  mode  change.  */ 

op_pk_nfd_set  {tk_pkptr.  "class", 
FDDI_TK_NONRESTRICTED) : 


else{ 

/*  Determine  the  class  of  the  current  captured  token.  */ 

op_pk_nfd_get  (tk_pkptr,  "class’, 

&current_tk_cl ass ) ; 

/*  When  not  in  restricted  mode,  this  mode  may  be  entered  */ 

/*  if  the  passed  packet  has  the  appropriate  token  class  requested,  */ 
/*  and  the  token  is  not  already  restricted.  */ 

if  (tk_class  —  FDDI_TK_RESTRICTED  && 
current_tk_cl ass  !«  FDDI_TK_RESTRICTED) 


/*  Enter  restricted  mode.  */ 

restricted  »  1: 


/*  Store  the  address  of  the  resticted  peer  station.  */ 
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1038 

/* 

1039 

1040 

1041 

/* 

1042 

1043 

1044 

1045 

res 

1046 

1047 

1048 

/* 

1049 

/* 

1050 

1051 

1052 

/* 

1053 

1054 

/* 

1055 

1056 

1057 

1058 

/* 

1059 

/* 

1060 

/* 

1061 

/* 

1062 

/* 

1063 

1064 

1065 

1066 

1067 

1068 

1069 

1070 

1071 

1072 

1073 

1074 

/*  : 

1075 

/*  1 

1076 

/*  1 

1077 

/» 

1078 

/* 

1079 

op_pk_nfd_get  (pkptr.  "dest.addr" 
8idest_addr[res_peer3 ) ; 


op_pk_nfd_set  (tk_pkptr,  "class’, 
FODI_TK_RESTRICTEO): 
op_pk_nfd_set  {tk_pkptr,  ‘res_station" , 


) 


op_pk_send_de1ayed  (pkptr,  FDDI_PHY_STRM_OUT, 
accum_bandw1dth  +  Fddi_Prop_Delay ) ; 


*/ 

08r 

*/ 


tht_va1ue  +-  tx_time: 
accuni_bandwidth  tx_time; 


num_f  ranies_sent-M-; 

num_bi ts_sent  +-  pk_len; 


}/*  closes  the  'while'  loop  *! 
if  (punt  =-  1)  /*  If  the  'while'  loop  was  broken,  */ 

{ 

punt  “  0:/*  then  reset  the  'break'  marker,  */ 
break;/*  and  break  out  of  the  'for'  loop  too.  */ 

} 


)/*  closes  the  'for'  loop. 


*/ 

*/ 


Since  the  token  is  about  to  be  sent,  its  transmission  time 
must  be  reflected  in  the  accumulated  bandwidth.  This  is  not 
done  in  the  ISSUE_TK  state  because  when  the  token  is  merely  */ 
repeated,  full  transmission  delay  is  not  required,  only  */ 
a  small  delay  for  repeating.  */ 

accum_bandwidth  +-  FDDIC_TOKEN_TX_TIME : 
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/*  If  the  station  has  no  more  data  to  send  (synchronous  or  */ 

/*  asynchronous),  it  should  indicate  this  to  the  token  acceleration  *! 
/*  mechanism  by  deregistering  its  interest  in  the  token.  */ 

/*  27DEC94:  the  original  code  must  be  modified  to  include  a  check  */ 
/*  of  subqueues.  -Nix  */ 
q_check  -  1 : 

for  (i  -  NUM_PRI0S  -  1:  i  <  -1:  i--) 

( 

if  (op_subq_stat  (i.  OPC_QSTAT_PKSIZE)  —  0.0) 

{ 

q_check  -  0; 

) 

else  { 

q_check  =1: 
break: 


if  (tk_registered  &&  q_check  —  0) 
{ 

tk_registered  -  0; 
fddi_tk_deregi ster  {); 


/**  state  (TX.OATA)  exit  executives  **/ 

FSM_STATE_EXIT_F0RCED  (9.  state9_exi t.exec .  "TX.DATA’) 


/**  state  (TX_DATA)  transition  processing  **/ 
FSM_TRANSIT_F0RCE  (2.  state2_enter_exec , 


/**  state  (CLAIM)  enter  executives  **/ 

FSM_STATE_ENTER_UNFORCED  (10.  statel0_enter_exec . 


■CLAIM") 


/♦  Obtain  this  station’s  object  id  which  is  used  */ 
/*  to  access  the  station’s  attribute  assignments.  */ 
my_objid  =  op_id_self  (); 


/*  Using  the  object  id,  obtain  the  ring  id.  */ 

/*  The  ring  id  is  used  by  macros  defined  in  the  */ 
/*  header  block  to  obtain  "ring-global"  values,  */ 
/*  values  shared  by  all  stations  on  a  ring.  */ 

op_ima_obj_attr_get  (my_objid.  "ring_id", 

/*  Initialize  global  variable  values.  */ 

Fddi_Tk_Bl ocked  =  0; 

Fddi  Num  Stations  =  0: 


&ring_id) : 
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1124 


Fddi_Num_Registered  -  0; 


1125  /*  Using  the  object  id.  obtain  the  value  of  ■T_Req’,  */ 

1126  /*  the  value  of  TTRT  requested  by  this  station.  */ 

1127  op_ima_obj_attr_get  (my_objid,  "T_Req".  4T_Req); 

1128  /*  The  lowest  value  of  T_Req  becomes  T_0pr  for  the  ring  as  a  whole.  */ 

1129  if  (T_Req  <  Fddi_T_0pr  ||  Fddi_Claim_Start) 

1130  ( 

1131  /*  The  T_Req  for  this  station  is  lower  than  any  other  to  date  */ 

1132  /*  so  it  is  installed  in  the  T_0pr  variable.  */ 

1133  Fddi_T_0pr  -  T_Req: 

1134  /*  The  flag  indicating  that  the  claim  process  is  just  */ 

1135  /*  beginning  may  now  be  cleared.  */ 

1136  Fddi_Cl aim_Start  -  0; 

1137  ) 

1138  /*  Request  a  self  interrupt  from  the  Simulation  Kernel  at  the  current  */ 

1139  /*  time  so  that  after  all  stations  have  executed  their  claim  states,  */ 

1140  /*  they  can  proceed  with  initializations.  This  is  necessasary  */ 

1141  /*  because  some  initializations  are  based  in  the  value  of  T_0pr  */ 

1142  /*  and  it  must  therefore  be  known  that  all  stations  have  settled  */ 

1143  /*  on  a  final  value.  */ 

1144  op_intrpt_schedule_self  (op_sim_time  ().  0); 

1145  ) 

1146  /**  blocking  after  enter  executives  of  unforced  state.  **/ 

1147  FSM.EXIT  (21 .fddi_raac_mult) 

1148  /**  state  (CLAIM)  exit  executives  **/ 

1149  FSM_STATE_EXIT_UNF0RCED  (10.  statel0_exi t_exec .  "CLAIM") 

1150  { 

1151  } 

1152  /**  state  (CLAIM)  transition  processing  **/ 

1153  FSM_TRANSIT_F0RCE  (0.  state0_enter_exec ,  :) 

1154  /* . */ 

1155  ) 

1156  FSM_EXIT  ( 10 . fddi_mac_mu1 1 ) 

1157 

1158 

1159 

1160 
1161 
1162 

1163  FIN  ( fddi_mac_mul t_svar  (prs_ptr)) 


fddi_mac_mu1 t_s var  ( prs_ptr , var_name , var_p_ptr ) 
fddi_mac_mul t_state  *prs_ptr; 
char  *var_name.  **var_p_ptr: 
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1164 

1166 

1166 

1167 

1168 

1169 

1170 

1171 

1172 

1173 

1174 

1175 

1176 

1177 

1178 

1179 

1180 
1181 
1182 
1183 
1164 

1185 

1186 

1187 

1188 

1189 

1190 

1191 

1192 

1193 

1194 


*var_p_ptr  •»  VOS_NIL; 

if  ( Vos_Stri ng_Equal  (''ring_id*  ,  var_name)) 

*var_p_ptr  -  (char  *)  (&prs_ptr->sv_ring_id) : 

If  { Vos_Str1  ng_Equal  CTHT*  .  var_naroe)) 

*''ar_p_ptr  -  (char  *)  (&prs_ptr->sv_THT) : 
if  ( Vos_Stri ng_Equal  (■T_Req"  .  var_name)) 

*var_p_ptr  -  (char  *)  (&prs_ptr->sv_T_Req) : 
if  ( Vos_String_Equal  (■T_Pri*  .  var_name)) 

*var_p_ptr  -  (char  *)  (prs_ptr->sv_T_Pri ) : 
if  ( Vos_String_Equal  (■my_objid*  .  var_name)) 
*var_p_ptr  -  (char  *)  (iprs_ptr->sv_my_objid) : 

■f  ( Vos_String_Equal  ( 'spawn_token"  .  var_name)) 
*var_p_ptr  -  (char  *)  (&prs_ptr->sv_spawn_token ) ; 
if  ( Vos_String_Equal  ( ''my_address’  .  var_name)) 
*var_p_ptr  -  (char  *)  (&prs_ptr->sv_my_address ) : 
if  ( Vos_String_Equa1  ("tk_pkptr*  .  var_name)) 

*var_p_ptr  -  (char  *)  (&prs_ptr->sv_tk_pkptr ) : 
if  ( Vos_String_Equal  ( ’sync_bandwidth*  .  var_nanie)) 
*var_p_ptr  -  (char  *)  (4prs_ptr->sv_sync_bandwi dth ) : 
if  ( Vos_String_Equal  ("sync_pc‘  ,  var_name)) 

*var_p_ptr  -  (char  *)  (&prs_ptr->sv_sync_pc ) ; 
if  (Vos_Stri ng_Equa1  ('restricted*  .  var_name)) 
*var_p_ptr  -  (char  *)  (&prs_ptr->sv_restricted ) : 
if  ( Vos_String_Equal  (’res_peer'  ,  var_name)) 

*var_p_ptr  =  (char  *)  (&prs_ptr->sv_res_peer ) : 
if  ( Vos_String_Equa1  ( 'tk_registered'  .  var_name)) 
*var_p_ptr  »>  (char  *)  (&prs_ptr->sv_tk_registered) : 
if  ( Vos_Stri  ng_Equal  ( "to_nc_ici_ptr'  .  var^name)) 
*var_p_ptr  -  (char  *)  (&prs_ptr->sv_to_11c_ici_ptr) : 
if  (Vos_String_Equal  ( 'tk_trace_on'  .  var_name)) 
*var_p_ptr  *  (char  *)  (&prs_ptr->sv_tk_trace_on) : 


1195  POUT; 

1196  1 


1197 

1198 

1199 

1200 
1201 
1202 

1203 

1204 

1205 


void 

fddi_mac_mu1t_di ag  () 


/*  Packets  and  Id’s  */ 


Packet* 

Packet* 

Packet* 

Packet* 

Ici* 


mac_frame_ptr : 
pdu_ptr : 
pkptr : 
data_pkptr : 
ici.ptr : 


1206 

1207 

1208 

1209 

1210 


/*  Packet  Fields 
i  nt 
i  nt 
i  nt 

static 


and  Attributes  */ 
req_pri .  svc_class.  req_tk_cl ass : 
f rame_control ,  src_addr: 
pk_1en,  pri_leve1: 
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1211 


int 


*da_ptr.  dest_addr[] : 


1212  /*  Token  -  Related  */ 

1213  Int  tk_usable.  res_station,  tk_c1ass: 

1214  int  current_tk_cl  ass : 

1215  double  accum_sync; 

1216  /*  Timer  -  Related  */ 

1217  double  tx_time.  timer_remaining.  accum_bandwidth: 

1218  double  tht_value; 

1219  /*  Miscellaneous  */ 

1220  int  i : 

1221  int  spawn_station.  phy_arriva1; 

1222  char  error_str1ng  [512]: 

1223  int  num_frames_sent.  num_bits_sent: 

1224  /*  26DEC93:  loop  management  variables,  used  in  RCV_TK  */ 

1225  /*  and  ENCAP  states.  -Nix  */ 

1226  int  NUM.PRIOS: 

1227  int  punt; 

1228  int  q_check: 

1229  /*  08FEB94:  case  management  variables,  used  in  FR_REPEAT.  -Nix  */ 

1230  int  for_me: 

1231  int  count_addees : 

1232  /*  08MAR94:  "field  holding"  variables,  used  in  FR_REPEAT.  -Nix  */ 

1233  Packet*  1nfo_ptr: 

1234  FIN  (fddi_mac_mu1 t_diag  ()) 

1235  /*  Print  out  values  of  timers,  and  late  token  counter.  */ 

1236  /*  Also  print  out  data  about  restricted  mode.  */ 

1237  /*  (This  code  may  be  executed  by  the  simulation  debugger  */ 

1238  /*  by  invoking  the  command  ’modprint’).  */ 

1239  sprintf  (str  mers  (count  upwards):  TRT  (X.9g).  THT  (X.9g)", 

1240  fddi_timer_  ue  (TRT),  fdd1_timer_value  (THT)): 

1241  sprintf  (strl,  "Late.ct  (Xd)".  Late_Ct); 

1242  op_prg_odb_print_roajor  (strO,  strl.  0PC_NIL); 

1243  if  (restricted) 

1244  sprintf  (strO.  "token  is  in  restricted  dialog  with  (Xd)\n", 

1245  res_peer): 

1246  else  sprintf  (strO,  "token  is  unrestri cted\n" ) : 

1247  op_prg_odb_print_ma jor  (strO,  0PC_NIL); 

1248  FOUT: 

1249  ) 

1250  void 
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1251  fddi_mac_mu1  t_termi nate  () 

1252  { 

1253  /*  Packets  and  Id’s  */ 

1254  Packet*  mac_frame_ptr : 

1255  Packet*  pdu_ptr: 

1256  Packet*  pkptr: 

1257  Packet*  data_pkptr: 

1258  Ici*  ici_ptr: 

1259  /*  Packet  Fields  and  Attributes  */ 

1260  int  req_pr1 .  svc_class,  req_tk_cl ass : 

1261  int  f rame_contro1 .  src_addr: 

1262  int  pk_len.  pr1_level: 

1263  static 

1264  int  *da_ptr.  dest_addr[]: 

12K  /*  Token  -  Related  */ 

1266  int  tk_usable.  res_station.  tk_c1ass: 

1267  int  current_tk_cl ass : 

1268  double  accum_sync: 

1269  /*  Timer  -  Related  */ 

1270  double  tx_time.  timer_remaining.  accum_bandwidth: 

1271  double  tht_value: 

1272  /*  Miscellaneous  */ 

1273  int  i : 

1274  int  spawn_stat1on.  phy_arrival; 

1275  char  error_string  [512]: 

1276  int  num_frames_sent ,  num_bits_sent: 

1277  /*  26DEC93:  loop  management  variables,  used  in  RCV_TK  */ 

1278  /*  and  ENCAP  states.  -Nix  */ 

1279  int  NUM_PRI0S: 

1280  int  punt; 

1281  int  q_check; 

1282  /*  08FEB94:  case  management  variables,  used  in  FR_REPEAT.  -Nix  */ 

1283  int  for_me; 

1284  int  count_addees ; 

1285  /*  08MAR94:  "field  holding"  variables,  used  in  FR_REPEAT.  -Nix  */ 

1286  Packet*  info_ptr: 

1287  FIN  {fddi_mac_mu1t_terminate  ()) 

1288  FOUT: 

1289  ) 

1290  Compcode 

1291  fddi_mac_mul t_i ni t  (pr_state_pptr) 
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1292 

1293 

1294 


fd(li_mac_mult_state  ♦♦pr_state_pptr ; 

{ 

static  VosT_Cm_Obtype  obtype  -  0PC_NIL: 

1295  FIN  (fddi_mac_mult_1n1t  (pr_state_pptr ) ) 

1296  if  (obtype  —  OPC.NIL) 

1297  { 

1298  if  (Vos_Catmetn_Register  Cproc  state  vars  ( fdd1_mac_mul t ) ’ .  sizeof 

1299  (fdd1_mac_mult_state).  Vos_Nop.  iobtype)  •-  VOSC.FAILURE) 

1300  FRET  (OPC.COMPCODE.FAILURE) 

1301  } 

1302  if  ( (*pr_state_pptr  -  { fdd1_mac_mul t_state*)  Vos_Catmeni_A1 1  oc 

1303  (obtype.  1)T  —  0PC_NIL) 

1304  FRET  (0PC_C0MPC0DE_FAILURE) 

1305  else 

1306  { 

1307  (*pr_state_pptr) ->current_b1ock  -  20: 

1308  FRET  (0PC_C0MPC0DE_SUCCESS) 

1309  ) 

1310  ) 

1311  !**  The  procedures  defined  in  this  section  serve  **/ 

1312  /**  to  simplify  the  code  in  the  main  body  of  the  **/ 

1313  /**  process  model  by  providing  primitives  for  timer  **! 

1314  /**  manipulation..  **! 

1315  fddi_timer_disab1e  (t1mer_ptr) 

1316  Fdd1T_Timer*  t1mer_ptr: 

1317  { 

1318  /*  if  the  timer  is  already  disabled,  do  nothing  *! 

1319  if  (timer_ptr->enabled) 

1320  { 

1321  I*  disable  the  timer  */ 

1322  timer_ptr->enabled  -  0; 

1323  /♦  reassign  the  accumulated  time  so  far  */ 

1324  timer_ptr->accum  -  op_sim_t1me  ()  -  timer_ptr->start_time; 

1325  } 

1326  ] 

1327  fddi_timer_enable  (t1raer_ptr) 

1328  Fdd1T_T1mer*  t1mer_ptr: 

1329  { 

1330  /*  if  the  timer  is  already  enabled,  simply  return  */ 

1331  if  ( !tiroer_ptr->enabled) 

1332  { 

1333  /*  reenable  the  timer  *! 

1334  timer_ptr->enabled  -  1; 
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1335  /*  set  the  start  time  to  the  current  time  */ 

1336  /*  less  the  accumulated  time  so  far  */ 

1337  timer_ptr->start_t1me  -  op_slm_time  ()  -  tiraer_ptr->accum; 

1338  ) 

1339  1 

1340  fddi_timer_expi red  (t1mer_ptr) 

1341  FddiT_Timer*  t1mer_ptr: 

1342  ( 

1343  if  (fddi_timer_remain1ng  (timer_ptr)  <-  0,0) 

1344  return  1: 

1345  else  return  0; 

1346  } 


1347  double 

1348  fddi_timer_remain1ng  (t1mer_ptr) 

1349  FddiT_Timer*  t1mer_ptr; 

1350  ( 

1351  I*  If  the  timer  Is  enabled,  update  the  accumulated 

1352  if  (timer_ptr->enabled) 

1353  { 

1354  timer_ptr->accum  -  op_s1m_tirae  {)  -  timer 

1355  } 

1356  /*  return  the  timer  remaining  before  expiration  *! 

1357  /*  a  non-positive  value  indicates  an  expired  timer  */ 

1358  return  (t1mer_ptr->target_accum  -  t1mer_ptr->accum) : 

1359  ) 

1360  double 

1361  fddi_timer_va1ue  (timer.ptr) 

1362  FddiT_T1mer*  timer  ptr; 

1363  { 

1364  /*  if  the  timer  is  enabled,  update  the  accumulated  time  */ 

1365  if  (timer_ptr->enabled) 

1366  { 

1367  t1mer_ptr->accura  -  op_sira_time  ()  -  timer_ptr->start_t1me: 

1368  } 

1369  return  (timer  ptr->accum); 

1370  } 

1371  fdd1_timer_set_va1 ue  (tiraer.ptr,  value) 

1372  Fdd1T_T1mer*  t1mer_ptr; 

1373  double  value; 

1374  { 

1375  timer_ptr->accum  -  value: 

1376  ) 

1377  fddi_timer_copy  (from_t1mer_ptr,  to_timer_ptr) 


time  *! 

_ptr->start_time; 


165 


1378 

1379 

1380 

1381 

1382 

1383 

1384 

1385 

1386 

1387 

/* 

1388 

1389 

/* 

1390 

1391 

/* 

1392 

1393 

/* 

1394 

1395 

1396 

1397 

1398 

1399 

1400 

/* 

1401 

1402 

/* 

1403 

1404 

/* 

1405 

1406 

1407 

1408 

1409 

1410 

/* 

1411 

1412 

/* 

1413 

1414 

/* 

1415 

FddiT_T1mer*  f rom_timer_ptr: 

Fdd1T_T1raer*  to_t1raer_ptr; 

{ 

Vos_Copy_Memory  (froni_t1mer_ptr.  to_t1mer_ptr.  sizeof 
TFddlT.TimeD): 

) 

fdd1_tiraer_set  (t1mer_ptr,  duration) 

FddiT_T1nier*  t1mer_ptr: 

{ 

dear  out  accumulated  time  *! 
t1mer_ptr->accum  -  0.0; 

assign  the  timer  duration  */ 

timer_ptr->target_accum  -  duration; 

assign  the  current  time  *! 

t1mer_ptr->start_t1me  -  op_s1m_t1me  (): 

enable  the  timer  */ 

timer_ptr'>enabled  ■  1; 

) 


Fdd1T_T1mer* 

fddi  timer  create  ( ) 

( 

FddiT_T1mer*  t1mer_ptr; 

allocate  memory  for  a  timer  structure  */ 

t1mer_ptr  -  ( Fdd1T_T1mer*)  malloc  (sizeof  ( FddiT_Tlmer ) ) ; 

initialize  the  timer  In  the  disabled  mode  */ 
fddi_t1mer_1nit  (t1mer_ptr); 

return  the  timer’s  address  */ 
return  (timer_ptr); 

) 

fddi_timer_init  (timer_ptr) 

FddiT_Timer*  timer_ptr; 

{ 

the  timer  Is  Initially  disabled  */ 
timer_ptr->enabled  -  0; 

the  accumulated  time  Is  zero  */ 
timer_ptr->accum  -  0.0; 

the  target  accumulated  time  is  infinite  ♦/ 

timer_ptr->target_.accum  -  V0S_D0UBLE_INFINITY ; 
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1416 

1417 

1418 

1419 

1420 

1421 

1422 

1423 

/* 

1424 

/* 

1425 

1426 

1427 

/* 

1428 

1429 

1430 

1431 

1432 

1433 

/* 

1434 

/* 

1435 

/* 

1436 

1437 

/* 

1438 

1439 

/* 

1440 

1441 

1442 

1443 

1444 

1445 

1446 

1447 

1448 

/* 

1449 

/* 

1450 

/* 

1451 

the  start  time  Is  now  */ 

t1mer_ptr->start_t1me  -  op_sira_time  (); 

) 

fddi_station_register  (address,  objid) 

Objid  objid: 

Int  address; 

( 

Fill  an  entry  in  the  table  which  maps  station  */ 
addresses  to  OPNET  object  Ids  */ 

FIN  (fdd1_stat1on_reg1ster  (address,  objid)) 

Fdd1_Address_Table  [address]  -  objid: 

Keep  track  of  total  number  of  stations  on  the  ring  * 
Fdd1_Num_Stat1ons++; 

FOUT 

} 

fdd1_tk_reg1ster  () 

{ 

Register  the  station’s  intent  to  use  the  token.  */ 
This  should  be  done  whenever  an  unregistered  */ 
station  obtains  new  data  to  transmit.  *! 

FIN  (fddi_tk_regs1ster  ()) 

increase  the  number  of  registered  stations  */ 
Fddi_Num_Reg1 stered++; 

if  the  token  is  currently  blocked,  unblock  It  */ 
if  ( Fddi_Tk_Blocked  &&  Fdd1_Tk_Acce1erate) 

{ 

fdd1_tk_unblock  (): 

) 

FOUT 

} 

fddi_tk_deregi ster  () 

{ 

Cancel  the  station's  intent  to  use  the  token.  */ 
This  should  be  done  whenever  a  registered  */ 
station  exhausts  its  transmi ttable  data.  */ 

FIN  (fddi_tk_deregsister  ()) 


1452  /*  decrease  the  number  of  registered  stations  */ 

1453  Fddi_Num_Regi stered- - : 


1456  fddi_tk_1nd1cate_no_data  (token,  address,  delay) 

1457  Packet*  token: 

1458  Int  address: 

1459  double  delay: 

1460  ( 

1461  FIN  (fdd1_tk_ind1cate_no_data  (token,  address,  delay)) 

1462  /*  The  calling  station  is  indicating  that  it  has  captured  */ 

1463  /*  the  token,  but  has  no  data  to  send.  If  no  other  stations  */ 

1464  /*  have  data  to  send  either,  the  token  may  be  blocked  to  gain  */ 

1465  /*  simulation  efficiency.  */ 

1466  if  (Fddi_Num_Registered  0  Fddi_Tk_Accelerate) 

1467  { 

1468  fdd1_tk_block  (token,  address): 

1469  } 

1470  else{ 

1471  /*  If  the  token  cannot  be  blocked,  send  it  into  the  ring.  */ 

1472  op_pk_send_del ayed  (token.  FD0I_PHY_STRM_0UT. 

1473  delay  +  Fdd1_Prop_Delay): 

1474  ) 

1475  FOUT 

1476  } 

1477  fddi_tk_b1ock  (token,  address) 

1478  Packet*  token; 

1479  int  address; 

1480  1 

1481  int  i; 

1482  FIN  (fddi_tk_block  (token,  address)) 

1483  /*  Record  the  address  of  the  blocking  station  and  blocking  time.  */ 

1484  Fddi_Tk_B1ock_Base_Time  -  op_sim_time  (): 

1485  Fddi_Tk_Block_Base_Statlon  -  address: 

1486  if  (tk_trace_on  —  OPC.TRUE) 

1487  { 

1488  sprintf  (strO.  'Blocking  Token:  station  (Xd).  time  (X.9f)’, 

1489  Fddi_Tk_B1ock_Base_Station.  Fddi_Tk_Block_Base_Time) ; 

1490  op_prg_odb_print_ma jor  (strO.  0PC_NIL): 

1491  ) 

1492  /*  Indicate  that  the  token  is  blocked  */ 

1493  Fddi_Tk_Blocked  -  1; 

1494  /*  discard  the  token  packet:  another  one  will  be  */ 

1495  /*  created  when  the  token  is  unblocked.  */ 

1496  op_pk_destroy  (token); 


1497  /*  Cancel  TRT  timers  at  all  MAC  interfaces:  otherwise  these  */ 

1498  /*  timers  may  continue  to  expitr  during  the  Idle  period.  */ 

1499  /*  generating  unnecessary  events.  */ 

1500  If  (tk_trace_on  —  0PC_TRUE) 

1501  { 

1502  sprintf  (strO,  'Canceling  timers  for  (Xd)  stations', 

1503  Fddi_Num_Stat1ons) : 

1504  op_prg_odb_pr1nt_major  (strO.  OPC_NIL): 

1505  ) 

1506  for  (1  -  0;  1  <  Fdd1_Num_Stat1ons :  1++) 

1507  { 

1508  /*  Retain  the  time  at  which  the  TRT  would  have  expired:  */ 

1509  /*  this  is  used  for  calculations  when  the  tokeh  is  */ 

1510  /*  reinjected  into  the  ring.  */ 

1511  Fdd1_Trt_Exp_T1me  [i]  -  op_ev_time  (Fddi_Trt_Hand1e  [i]): 

1512  /*  Cancel  the  TRT  expiration  event.  */ 

1513  op_ev_cance1  ( Fddi_Trt_Handle  [i]): 

1514  ) 

1515  FOUT 

1516  1 

1517  fddi_tk_unblock  () 

1518  ( 

1519  double  e1apsed_time.  first_tk_rx,  last_tk_rx; 

1520  double  tk_lap_time.  next_time.  current_time: 

1521  double  dbl_num_hops .  num_tk_rx.  floor  ().  ceil  (): 

1522  int  1,  num_hops,  next_station: 

1523  FIN  {fddi_tk_unblock  ()) 

1524  /*  reset  the  blocking  indicator  */ 

1525  Fddi_Tk_Blocked  -  0: 

1526  /*  Get  the  current  time,  used  for  m.ny  calculations  below  */ 

1527  current_time  -  op_sim_time  (): 

1528  if  (tk_trace_on  --  0PC_TRUE) 

1529  { 

1530  sprintf  (strO.  "Unblocking  token  for  ring  (Xd)",  ring_id): 

1531  op_prg_odb_print_ma jor  (strO.  0PC_NIL): 

1532  ) 

1533  /*  For  all  stations  on  the  ring,  adjust  TRT  timer  and  Late_Ct  flag.  */ 

1534  for  (i  =0:  i  <  Fdd1_Num_Stations :  1++) 

1535  { 

1536  if  (tk_trace_on  —  0PC_TRUE) 

1537  { 

1538  sprintf  (strO.  "adjusting  state  of  station  (Xd)",  i); 
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1539 

1540 

1541 

1542 

1543 

1544 

1545 

1546 

1547 

1548 

1549 

1550 

1551 

1552 

1553 


op_prg_odb_pr1nt_m1nor  (**.  strO.  OPC_NIL): 

) 

/*  Calculate  number  of  hops  separating  station  i  from  block  base 
station.  */ 

/*  In  special  case  where  i  is  the  base  station,  the  token  must  run  a 
full  */ 

/*  lap  before  returning.  */ 

if  (i  !■  Fddi_Tk_Block_Base_Station) 

{ 

num_hops  -  (i  -  Fddi_Tk_Block_Base_Station)  % 
Fddi_Num_Stations : 
if  (num_hops  <  0) 

num_hops  -  Fdd1_Num_Stations  +  num_hops: 

} 

else  num_hops  -  Fdd1_Num_Stations: 


1554  /*  Calculate  first  time  at  which  token  would  have  been  received  by 

1555  station  i.  */ 

1556  /*  Note  that  initial  release  of  token  from  base  station  takes  a 

1557  different  */ 

1556  /*  amount  of  time  than  repeating  of  token  by  other  stations.  Thus,  the 

1559  first  */ 

1560  /*  hop  is  assumed,  and  the  base  time  is  augmented  by  the  time  required 

1561  to  */ 

1562  /*  complete  it.  */ 

1563  first_tk_rx  -  Fddi_Tk_Block_Base_Time  ♦  FODIC_TOKEN_TX_TIME  + 

1564  Fddi_Prop_Del ay  +  (num_hops  *  1)  *  Fddi_Tk_Hop_Del ay : 


1565 

1566 

1567 

1568 

1569 

1570 

1571 


if  (tk_trace_on  0PC_TRUE) 

{ 

sprintf  (strO,  "station  is  (Xd)  hops  from  base",  num_hops) 
sprintf  (strl,  "first  receipt  of  token  would  be  at  (X.9f)" 
fi rst_tk_rx) ; 

op_prg_odb_print_minor  (strO,  strl,  0PC_NIL): 

) 


1572 

1573 

1574 

1575 

1576 

1577 

1578 

1579 

1580 


/*  Case  1:  the  token  would  not  yet  have  been  received  by  station  i.  */ 
if  (first_tk_rx  >  current_time) 

{ 

/*  Case  la:  the  TRT  at  station  i  would  not  yet  have  expired.  */ 
if  { Fddi_Trt_Exp_Time  [i]  >  current_time ) 

{ 

/*  Late_Ct  remains  at  1  original  value:  only  the  TRT  needs  */ 

/*  to  be  started  again,  rtith  the  same  expiration  time.  */ 

TRT_SET  (i,  Fddi_Trt_Exp_Time  [1]) 


1561 

1582 

1583 

1584 


if  ( tk_trav;e_on  0PC_TRUE) 

{ 

sprintf  (StrO,  "Restoring  TRT  to  previous  exp.  time 
(X.9f)*,  Fddi_Trt_Exp_Time  [i]); 
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1585  op_prg_odb_print_ni1nor  (’Token  would  not  be  received 

1586  and  TRT  not  expired’.  strO.  0PC_NIL): 

1587  ) 

1588  ) 

1589  /*  Case  lb:  the  TRT  at  station  i  would  have  expired.  */ 

1590  else 

1591  { 

1592  /*  Late_Ct  would  have  been  set:  also  the  timer  would  have  been 

1593  rescheduled  */ 

1594  /*  for  an  entire  TTRT  at  the  time  of  expiration.  */ 

1595  Fddi_Late_Ct  [i]  -  1: 

1596  TRT_SET  (i.  (Fddi_T_0pr  +  Fddi_Trt_Exp_Time  [i])) 


1597 

1598 

1599 

1600 
1601 
1602 

1603 

1604 

1605 


if  (tk_trace_on  —  0PC_TRUE) 

{ 

sprintf  (strO.  ’Restoring  TRT  to  proper  exp.  time 
(%.9f)’.  Fdd1_T_0pr  +  Fddi_Trt_Exp_Time  [i]): 
op_prg_odb_pr1nt_m1nor  (’Token  would  not  be  received 
and  TRT  would  have  expired’,  strO.  0PC_NIL): 

} 


1606  /*  Case  2:  the  token  would  have  been  received  (perhaps  more  than  once). 

1607  */ 

1608  else 

1609  { 

1610  /*  Calculate  the  number  of  times  the  token  would  have  been  received  */ 

1611  /*  not  including  the  first  receipt.  */ 

1612  tk_1ap_time  -  Fddi_Tk_Hop_Del ay  *  Fddi_Num_Stations ; 

1613  num_tk_rx  -  floor  ( (current_time  -  first_tk_rx)  / 

1614  tk_1  ap_time) ; 

1615  /*  Calculate  the  latest  time  at  which  the  token  would  have  been 

1616  received.  */ 

1617  last_tk_rx  -  first_tk_rx  +  (num_tk_rx  *  tk_l ap_time) : 


1618  /*  Clear  Late_Ct  and  schedule  timer  to  expire  at  last  receipt  of  token 

1619  */ 

1620  /*  plus  one  full  TTRT.  */ 

1621  Fddi_Late_Ct  [i]  -  0; 

1622  TRT_SET  (i.  (1ast_tk_rx  +  Fddi_T_0pr)) 

1623  if  (tk_trace_on  =-  0PC_TRUE) 

1624  { 

1625  sprintf  (strO,  "token  received  (*g)  times,  last  receipt 

1626  at  (J.9f)’,  num_tk_rx  +  1.0,  1 ast_tk_rx) ; 

1627  sprintf  (strl,  ’Restoring  TRT  to  proper  exp.  time 

1628  (*.9f)".  1ast_tk_rx  +  Fddi_T_0pr): 

1629  op_prg_odb_pr1nt_minor  (’Token  would  have  been  received: 

1630  Late_Ct  is  cleared’,  strl.  strO,  0PC_NIL): 
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1631 

1632 

1633 

1634 

/* 

1635 

1636 

/* 

1637 

1638 

/* 

1639 

1640 

/* 

1641 

1642 

/* 

1643 

1644 

/* 

1645 

/* 

1646 

1647 

1648 

/* 

1649 

1650 

/* 

1651 

/* 

1652 

/* 

1653 

/* 

1654 

/* 

1655 

1656 

1657 

1658 

1659 

/♦ 

1660 

/* 

1661 

1662 

1663 

/* 

1664 

1665 

/* 

1666 

/* 

1667 

1668 

1669 

/* 

1670 

/* 

1671 

/* 

1672 

1673 

) 

} 

} 

compute  the  time  since  the  token  was  blocked  */ 

elapsed_t1me  ■  current_t1me  -  Fdd1_Tk_Block_Base_Time: 

compute  the  number  of  hops  completed  on  the  ring.  For  the  first  hop 
*/ 

the  token  Is  transmitted  directly,  not  repeated.  For  all  remaining 
*/ 

hops,  the  delay  Is  the  station  latency  plus  the  propagation  delay. 

*/ 

Thus,  the  first  hop  is  assumed,  and  the  remaining  time  for 
additional*/ 

hops  is  computed  beginning  at  the  time  where  the  token  enters  the  */ 
base  station's  downstream  neighbor  */ 

dbl_num_hops  -  1,0  +  (el apsed_t1me  -  FDDIC_TOKEN_TX_TIME  - 
Fdd1_Prop_Delay)  /  Fddi_Tk_Hop_Delay; 

If  the  token  was  unblocked  In  less  time  than  It  would  have  taken  to 
*/ 

be  fully  transmitted  by  the  base  station,  dbl_num_hops  will  be  */ 
negative.  However,  1  full  hop  would  still  be  required  before  the  */ 
token  could  be  used,  since  the  station  had  already  committed  to  */ 
Issuing  the  token.  Thus,  the  actual  of  number  of  hops  should  never  */ 
be  less  than  I,  If  It  Is.  round  It  to  1.  */ 
if  (dbl_nura_hops  <  1.0) 
dbl_num_hops  -  1.0: 
else 
{ 

In  all  other  cases,  round  the  number  of  hops  up  to  the  nearest  */ 
integer  value.  If  already  an  integer,  then  leave  as  is.  */ 
dbl_num_hops  -  ceil  {dbl_num_hops ) ; 

} 


Obtain  an  Integer  equivalent  of  dbl_num_hops .  */ 
num_hops  -  dbl_num_hops ; 

Based  on  the  number  of  hops  and  the  base  station,  compute  the  */ 
next  station  where  the  token  will  appear.  */ 

next_station  -  (num_hops  +  Fdd1_Tk_Block_Base_Station)  X 
Fddi_Num_Stat1ons : 

Compute  the  time  at  which  the  token  will  appear  there.  */ 

Again,  assume  the  first  hop  occurred,  and  measure  time  */ 
from  there  forward.  */ 

next_time  -  Fdd1_Tk_Block_Base_Time  +  ( FDDIC_T0KEN_TX_TIME  + 
Fddi_Prop_Delay )  +  (dbl_num_hops  -  1.0)  *  Fddi_Tk_Hop_Del ay : 
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OPC_TRUE) 


1674 

1675 

1676 

1677 

1678 

1679 

1680  /*  reinject  the  token  at  that  station  */ 

1681  fdd1_tk_1nject  (next_stat1on.  next_t1me): 

1682  FOUT 

1683  } 

1684  fdd1_tk_1nject  (address.  arv_t1rae) 

1685  Int  address; 

1686  double  arv_t1rae; 

1687  { 

1688  /*  Re-Insert  the  token  Into  the  ring  after  an  Idle  period,  */ 

1689  FIN  {fdd1_tk_1nject  (address.  arv_time)) 

1690  /*  The  token  Is  recreated  and  reinserted  onto  the  ring  */ 

1691  /*  at  the  specified  station  which  is  not  necesssarlly  the  */ 

1692  /*  station  now  requesting  the  token,  *! 

1693  I*  The  station  which  will  r  nsert  the  token  Is  */ 

1694  /*  asked  to  do  so  by  means  a  remote  Interrupt.  */ 

1695  op_1ntrpt_schedule_remote  (arv_t1me.  FDDIC_TK_INJECT. 

1696  Fdd1_Address_Tab1e  [address]); 

1697  FOUT 

1698  ) 

1699  fdd1_1oad_frame_attrs  (dest_addr_ptr .  svc_class_ptr.  pr1_level_ptr) 

1700  Int  *dest_addr_ptr.  *svc_c1ass_ptr.  *pri_leve1_ptr ; 

1701  { 

1702  Int  NUM.PRIOS.  1;  /*  26JAN94  */ 

1703  Packet  *pkptr; 

1704  FIN  (fdd1_1oad_frame_attrs  (dest_addr_ptr .  svc_class_ptr. 

1705  pr1_leve1_ptr) ) 

1706  /*  remove  next  packet  In  queue  *! 

1707  /*  27DEC94:  loop  structure  superimposed  to  handle  a  bank  of  subqueues. 

1708  */ 

1709  /*  Extract  the  packet  with  the  highest  priority,  that  is,  the  packet 

1710  */ 

1711  /*  at  the  head  of  the  highest-numbered  subqueue  containing  packets. 

1712  */ 

1713  /*  Note  that  the  C  language  vector  numbering  convention  numbers  the 

1714  */ 

1715  /*  subqueues  from  0  to  7,  while  FDDI  convention  is  to  number  the  */ 


If  (tk_trace_oii  — 

{ 

sprintf  (strO,  "Re-Introducing  token  at  station  (Xd).  at  time 
(X.9f)’.  next_station.  next_t1me); 
op_prg_odb_pr1nt_minor  (strO.  0PC_NIL); 

) 
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1716 

/* 

1717 

/* 

1718 

/* 

1719 

/* 

1720 

1721 

/* 

1722 

/* 

1723 

1724 

1725 

1726 

1727 

1728 

1729 

1730 

1731 

1732 

/* 

1733 

1734 

1735 

/* 

1736 

1737 

1738 

/* 

1739 

1740 

1741 

corresponding  asynchronous  priorities  from  1  to  8.  This  Is  */ 
reconciled  In  the  statistical  outputs  available  In  the  Analysis  */ 
Editor,  where  labels  are  assigned  accordingly.  Also  note  that  */ 
synchronous  traffic  is  assigned  priority  8  as  an  artifice  to  allow 
*! 

routing  through  a  separate  subqueue,  by  which  statistics  may  be  */ 
gathered  for  traffic  by  class  and  by  priority.  -N1x  */ 

NUM_PRI0S  -  9: 

for  (1  -  NUM.PRIOS  -  1:  i  >  -1:  1--) 

{ 

if  (op  subq_stat  (1.  OPC_QSTAT_PKSIZE)  >  0.0) 

{ 

pkptr  “  op_subq_pk_remove  (1.  0PC_QP0S_HEAD) : 
break: 


) 

extract  the  fields  of  interest  */ 

op_pk_nfd_get  (pkptr.  *dest_addr*.  dest_addr_ptr ) : 
op_pk_nfd_get  (pkptr.  *svc_class*.  svc_class_ptr) ; 

only  read  priority  level  1f  frame  Is  asynchronous  */ 
if  (*svc_cl ass_ptr  —  FD0I_SVC_ASYNC) 

op_pk_nfd_get  (pkptr.  *pr1*.  pr1_level_ptr ) ; 

replace  the  packet  on  the  proper  subqueue  */ 
op  subq  pk_1nsert  (1.  pkptr.  0PC_QP0S_HEAD) ; 

FOUT 

1 
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APPENDIX  F.  SOURCE  "C"  CODE 


"fddl_5en_multpr.c" 


The  line  numbering  in  this  appendbc  is  used  for  reference  within  this  thesis  only,  and 
does  not  correspond  with  that  seen  in  OPNET^s  text  editors. 


1  /*  Process  model  C  form  file:  fddi_gen_mu1t.pr .c  */ 

2  /*  Portions  of  this  file  Copyright  (C)  MIL  3.  Inc.  1992  */ 

3  /*  OPNET  system  definitions  */ 

4  ^include  <opnet.h> 

5  ^include  *fddi_gen_mult.pr.h* 

6  FSM_EXT_OECS 

7  /*  Header  block  */ 

8  ^define  MAC_LAYER_OUT_STREAM  0 


9 

/*  define  possible  service  classes  for  frames 

10 

^define  FDDI.SVC.ASYNC 

0 

11 

^define  FDDI_SVC_SYNC 

1 

12 

/*  define  token  classes  •/ 

13 

^define  FDDI_TK  NONRESTRICTED 

0 

14 

^define  FDDI_TK_RESTRICTEO 

1 

15 

/*  07FEB94;  define  the  number 

of  stations 

16 

^define  NUM.STATIONS  50 

17 

/*  a  global  counting  variable 

*/ 

18 

/*  nt  genARRIVAL  -  0;  */ 

19 

/*  State  variable  definitions 

*/ 

20 

tvpedef  struct 

21 

{ 

22 

FSM  SYS  STATE 

23 

Distribution*  sv_i nter_di st_ptr ; 

24 

Distribution*  sv_len 

_dist_ptr; 

25 

Di stri but ion*  sv_dest_dist_ptr; 

26 

Distribution*  sv_pkt 

_prior1ty_ptr : 

27 

Objid  sv_mac 

_objid: 
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28 

29 

30 

31 

32 

33 

34 

35 

36 

37 
36 

39 

40 

41 

42 

43 


Objid 

Int 

int 

Int 

Int 

int 

double 

double 

double 

Ici* 

Distribution* 

int 

int 

int 

i  nt 


sv_my_id: 

s  v_l ow_des  t_a  dd  r : 
sv_h1gh_dest_addr : 
sv_stat1on_addr: 
s  v_l ow_p  kt_p  r 1 0  r 1 ty ; 
sv_high_pkt_pri ori  ty ; 
sv_arri val_rate: 
sv_mean_pk_len: 
sv_async_niix: 
sv_mac_iciptr; 
sv_nuni_addees_d1st_ptr : 
sv_nuni_addees : 
sv_rain_nura_addees ; 
sv_max_nuni_addees : 
sv_dest_addr[NUM_STATIONS+l] : 


)  fddi_gen_niult_state: 


44 

y/define 

pr_state_ptr 

45 

SimI_Mod_State_Ptr 1 

46 

y/defi  ne 

inter_d1st_ptr 

47 

yydefine 

1en_d1 st_ptr 

48 

y/define 

dest_d1st_ptr 

49 

y/define 

pkt_priority_ptr 

50 

y/define 

mac_objid 

51 

yydefine 

ffly_id 

52 

y/define 

1ow_dest_addr 

53 

yydef  ine 

high_dest_addr 

54 

#define 

stat1on_addr 

55 

yydefine 

low_pkt_pr1or1ty 

56 

^define 

high_pkt_pr1or1ty 

57 

yydef  ine 

arri val_rate 

58 

y/define 

mean_pk_1en 

59 

yMefine 

async_mi x 

60 

y/define 

mac_iciptr 

61 

yydefine 

num_addees_d1st_ptr 

62 

yydefine 

num_addees 

63 

y/define 

mi n_num_addees 

64 

yydef  ine 

max_num_addees 

65 

yydef  i  ne 

dest_addr 

({fddi_gen_mult_state*) 

pr_state_ptr->sv_inter_dist_ptr 
pr_state_ptr->sv_len_di st_ptr 
pr_state_ptr*>sv_dest_di st_ptr 
pr_state_ptr*>sv_pkt_priori ty^ptr 
pr_state_ptr • >s v_mac_ob j i d 
pr_s  ta  t e_pt  r - >s  v_roy_i d 
pr_state_ptr->sv_l ow_dest_addr 
pr_state_ptr->sv_h1gh_dest_addr 
pr_state_ptr->sv_station_addr 
pr^state^ptr • >sv_l ow_pkt_pri ori ty 
pr_state_ptr->sv_high_pkt_pr1or1 ty 
pr_state_ptr*>sv_arri val_rate 
pr_5tate_ptr*>sv_mean_pk_len 
pr_state_ptr- >s v_async_mi x 
pr_state_ptr •>sv_mac_iciptr 
pr_state_ptr->sv_nutn_addees_d1  st_ptr 
pr_state_ptr->sv_num_addees 
pr_state_ptr->sv_roin_nuni_addees 
pr_state_ptr  -  >s  v_max_nuni_addees 
pr_state_ptr->sv_dest_addr 


66  /*  Process  model  interrupt  handling  procedure  */ 


67  void 

68  fddi_gen_mult  () 

69  { 


70 

Packet 

*pkptr ; 

71 

int 

pklen; 

72 

i  nt 

*da_ptr: 

73 

int 

i .  restricted; 
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74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

33 

94 

95 

96 

97 

98 

99 
100 

101 

102 

103 

104 

105 

106 

107 

108 

109 

110 
111 
112 
113 


int 

Int 


pkt_prio: 

nix; 


FSM_ENTER  (fddi.gen.muU) 

fsm_block_switch 

{ 

/* . »/ 

/**  state  (INIT)  enter  executives  **/ 

FSM_STATE_ENTER_UNFORCEO  (0.  stateO_enter_exec,  ’INIT*) 

{ 

/*  determine  id  of  own  processor  to  use  in  finding  attrs  *! 
my_id  -  op_id_se1f  (): 

/*  07FEB94:  determine  the  upper  and  lower  limits  for  multiple  */ 

/*  addressing  from  this  station.  -Nix  *! 

op_1ma_obj_attr_get  (my.id,  *min  num  addees",  4min_num_addees ) : 
op_ima_obj_attr_get  (my_id.  ’max  num  addees’,  imax_num_addees ) : 

/*  07FEB94:  set  up  a  distribution  for  the  number  of  stations  */ 

/*  receive  this  packet.  -Nix  *! 

num_addees_d1st_ptr  -  op_d1st_load  ( ’uniform_int’ , 
min_num_addees ,  max_num_addees) ; 

/*  determine  address  range  for  uniform  desination  assignment  */ 
op_ima_obj_attr_get  (my_id.  ’low  dest  address’. 

&low_dest_addr); 

op_ima_obj_attr_get  (my_id,  ’high  dest  address’, 

&high_dest_addr ) : 

/*  determine  object  id  of  connected  *mac’  layer  process  */ 

mac_objid  -  op_topo_assoc  (my_id.  0PC_T0P0_ASS0C_0UT. 
0PC_0BJMTYPE_M0DULE.  MAC_LAYER_OUT_STREAM) ; 

/*  determine  the  address  assigned  to  it  */ 

/*  which  is  also  the  address  of  this  station  */ 

op_1ma_obj_attr_get  (mac_obj1d.  ’station_address’ . 
&station_addr) : 

/*  set  up  a  distribution  for  generation  of  addresses  */ 

dtst_dist_ptr  -  op_dist_load  (’uniform_int’ .  low_dest_addr , 
high_dest_addr) ; 

/*  added  26DEC93  */ 

/*  determine  priority  range  for  uniform  traffic  generation  */ 
op_ima_obj_attr_get  (my_id,  ’high  pkt  priority’, 

&hi gh_pkt_pri ori ty ) : 

op_ima_obj_attr_get  (my_id.  ’low  pkt  priority’, 

&1 ow_pkt_pri ori ty ) ; 
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114  /*  set  up  a  distribution  for  generation  of  priorities  */ 

115  plct_pr1or1ty_ptr  -  op_d1st_load  { *un1forni_1nt‘ . 

116  low_pkt_pr1or1ty .  h1gh_p1ct_pr1or1ty ) ; 

117  /*  above  added  26DEC93  */ 

118  /*  also  determine  the  arrival  rate  for  packet  generation  */ 

119  op_1ma_obj_attr_get  (ray_1d,  "arrival  rate".  &arr1 val_rate) : 

120  /*  determine  the  mix  of  asynchronous  and  synchronous  *! 

121  /*  traffic.  This  Is  expressed  as  the  proportion  of  */ 

122  /*  asynchronous  traffic.  I.e  a  value  of  1.0  Indicates  */ 

123  /*  that  all  the  produced  traffic  shall  be  asynchronous.  */ 

124  op_1ma_obj_attr_get  (my_1d.  "async.mlx’,  4async_m1x); 

125  /*  set  up  a  distribution  for  arrival  generations  */ 

126  if  (arri val_rate  !-  0.0) 

127  { 

128  /*  arrivals  are  exponentially  distributed,  with  given  mean  */ 

129  1nter_d1st_ptr  -  op_d1st_load  ("constant" ,  1.0  / 

130  arri val_rate.  0.0); 

131  /*  determine  the  distribution  for  packet  size  */ 

132  op_1ma_obj_attr_get  (my.ld,  "mean  pk  length",  imean_pk_len) ; 

133  /*  set  up  corresponding  distribution  */ 

134  len_d1st_ptr  -  op_d1st_load  ("constant*.  mean_pk_len,  0.0); 

135 

136  /*  designate  the  time  of  first  arrival  */ 

137  fdd1_gen_schedu1e  (); 

138  /*  set  up  an  Interface  control  Information  (ICI)  structure  */ 

139  /*  to  communicate  parameters  to  the  mac  layer  process  */ 

140  /*  (it  Is  more  efficient  to  set  one  up  now  and  keep  It  */ 

141  /*  as  a  state  variable  than  to  allocate  one  on  each  packet  xfer)  *■/ 

142  mac_iciptr  -  op_ic1_create  ( ’fddi_mac_req’ ) ; 

143  ) 

144  ) 

145  /*★  blocking  after  enter  executives  of  unforced  state.  **! 

146  FSM.EXIT  ( 1 .fdd1_gen_mult) 

147  /**  state  (INIT)  exit  executives  **/ 

148  FSM_STATE_EXIT_UNF0RCED  (0.  state0_ex1t_exec .  "INIT") 

149  { 

150  } 

151  !**  state  (INIT)  transition  processing  **/ 

152  FSM_TRANSIT_F0RCE  (1.  statel_enter_exec .  ;) 

153  /* . */ 
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154  !**  state  (ARRIVAL)  enter  executives  **! 

155  FSM_STATE_ENTER_UNFORCED  (1.  statel_enter_exec .  ’ARRIVAL*) 

156  { 

157  /*  determine  the  length  of  the  packet  to  be  generated  */ 

158  pklen  -  op_d1st_outcome  (len_dist_ptr) ; 

159  /*  07FEB94:  re- i ni t1 al ize  the  destination  address  array  */ 

160  /*  to  zeros.  -Nix  */ 

161  for  (1  -  0:  i  <  NUM_STATI0NS+1 ;  1-M-) 

162  { 

163  dest_addr[i]  -  0: 

164  ) 

165  /*  determine  the  destination  */ 

166  I*  don't  allow  this  station’s  address  as  a  possible  outcome 

167  /*  gen_packet:  */ 

168  /*  dest_addr  -  op_d1st_outcome  (dest_dist_ptr) :  */ 

169  /*  if  (dest_addr  !-  -1  &&  dest_addr  “  stat1on_addr )  *! 

170  /*  goto  gen_packet:  */ 

171  /*  07FEB94:  determine  the  destinations.  -Nix  */ 

172  /*  Determine  the  number  of  stations  to  receive  this  packet  */ 

173  num_addees  -  op_dist_outcome  (num_addees_dist_ptr ) ; 

174  /*  Find  these  stations,  using  num_addees  as  a  counter.  -Nix  */ 

175  for  (i  -  num_addees;  i  >  0;  1--) 

176  { 

177  gen_packet: 

178  nix  -  op_dist_outcome  (dest_dist_ptr) ; 

179  if  (dest_addr[nix]  —  1  l|  nix  —  station_addr ) 

180  { 

181  goto  gen_packet; 

182  ) 

183  dest_addrCnix]  -  1; 

184  ) 

185  /*  05MAR94:  because  the  op_pk_nfd_get( )  command  in  FR_REPEAT  */ 

186  /*  overwrites  the  first  field  with  the  array  address,  an  *1*1 

187  I*  offset  needs  to  be  applied  so  that  the  dest_array[0]  */ 

188  /*  contents  aren’t  lost:  that  is.  one  field  more  than  the  *1*1 

189  /*  number  of  stations  is  included  to  allow  a  one-step  shift  */ 

190  /*  that  will  preserve  the  address  array.  In  fddi_mac.  all  *! 

191  /*  references  to  dest_addr  must  allow  for  this  shift.  -Nix  */ 

192  for  (i-NUM_STATI0NS:  1>0;  i--) 

193  dest_addr[i]  -  dest_addr[i -1] ; 

194 

195  I*  26DEC94  &  29JAN94;  determine  its  priority  */ 

196  pkt_prio  -  op_d1st_outcome  (pkt_pr1ori ty_ptr ) ; 
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/*  create  a  packet  to  send  to  mac  */ 

pkptr  -  op_pk_create_fmt  ( *fdd1_nc_fr' ) : 

/*  assign  its  overall  size.  */ 

op_pk_total_si2e_set  (pkptr.  pklen): 

/*  assign  the  time  of  creation  */ 

op_pk_nfd_set  (pkptr,  ’cr_t1me",  op_sim_time  ()): 

/*  place  the  destination  address  into  the  ICI  */ 

/*  (the  protocol_type  field  will  default)  */ 

/*  15MAR94:  note  that  dest_addr  now  serves  as  a  */ 

/*  pointer  to  an  array  in  memory,  as  it  is  the  */ 

/*  name  of  an  array  of  what  will  be  Os  and  Is.  -Nix  */ 

op_ici_attr_set  (mac_iciptr.  “dest_addr*,  dest_addr): 

/*  assign  the  priority,  and  requested  token  class  */ 

/*  also  assign  the  service  class  *! 

!*  29JAN94:  the  fddi_llc_fr  format  is  modified  *! 

/*  to  include  a  “pri"  field.  -Nix  */ 

if  (op_dist  uniform  (1.0)  <-  async_mix) 

op_pk_nfd_set  (pkptr.  *pri'.  pkt.prio):/*  29JAN94  *! 
op_ici_attr_set  (mac_iciptr,  ’svc_class*,  F00I_SVC_ASYNC) ; 

op_1ci_attr_set  (mac^iciptr,  ’•pri",  pkt_prio);  /*  29JAN94 

*/ 

) 

el  se{ 

op_pk_nfd_set  (pkptr,  "pri*.  8):/*  29JAN94  */ 
op_ici_attr_set  (mac_iciptr,  *svc_class'.  FDDI_SVC_SYNC) : 
op_ici_attr_set  (mac_iciptr.  "pri".  8):  /*  29JAN94  */ 


/*  Request  only  nonrestricted  tokens  after  transmission  */ 
op_i ci_attr_set  (mac_iciptr.  *tk_class*, 
FDDI_TK_NONRESTRICTED) ; 

/*  send  the  packet  coupled  with  the  ICI  */ 
op_ici_1nstall  (mac_iciptr ) : 
ijp_pk_send  (pkptr,  MAC_LAYER_OUT_STREAM) : 

y  ★  * ! 

/*  17MAR94:  count  and  report  the  running  total  number  */ 

/*  of  packets  generated.  -Nix  */ 

/*  genARRIVAL  -h-;  */ 

/*  pri ntf( "Packets  generated:  %d\n",  genARRIVAL):  */ 
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237  /*  schedule  the  next  arrival  */ 

238  fdd1_gen_schedule  (); 

240  I*  18FEB94:  print  out  the  address,  and  the  contents.  */ 

241  /*  for  (i-0:  i<NUM_STATIONS+l :  i++)  */ 


242  /*  printf( "ARRIVAL:  Xd.  address:  XX;  contents:  Xd\n".  */ 

243  /■*  i.  &(dest_addr[i ] ) .  dest_addrCi ] ) ;  */ 

245  ) 

246  !**  blocking  after  enter  executives  of  unforced  state.  **/ 

247  FSM_EXIT  (3.fddi_gen_niult) 

248  /**  state  (ARRIVAL)  exit  executives  **/ 

249  FSM_STATE_EXIT_UNFORCED  (1.  statel.exi t_exec .  "ARRIVAL") 

250  { 

251  ) 

252  /**  state  (ARRIVAL)  transition  processing  **/ 

253  FSM_TRANSIT_FORCE  (1.  statel_enter_exec.  :) 

254  /* . */ 

255  } 


256  FSM.EXIT  (0.fdd1_gen_mult) 

257  ) 


258  void 

259  fddi_gen_mu1 t_svar  (prs.ptr, var_naroe, var_p_ptr) 

260  fddi_gen_mul t_state  *prs_ptr: 

261  char  *var_nanie.  **var_p_ptr: 

262  { 


263  FIN  (fdd1_.gen_niu1t_svar  (prs_ptr)) 


264 

265 

266 

267 

268 

269 

270 

271 

272 

273 

274 

275 

276 

277 

278 


*var_p_ptr  -  VOS.NIL; 

if  ( Vos_String_Equa1  ( "1nter_dist_ptr*  ,  var_name))  *var_p_ptr  - 
(char*)  (&prs_ptr->sv_1nter_dist_ptr ) : 
if  (Vos_String_Equa1  ( "len_dist_ptr"  .  var_nanie))  *var_p_ptr  ■ 
(char*)  (&prs_ptr->sv_len_dist_ptr) ; 
if  (Vos_Str1ng_Equal  ( "dest_dist_ptr"  ,  var_name))  *var_p_ptr  - 
(char*)  (4prs_ptr->sv_dest_d1st_ptr) : 
if  ( Vos_String_Equa1  ( "pkt_prior1ty_ptr"  .  var_name))  *var_p_ptr  - 
(char*)  (&prs_ptr->sv_pkt_priority_ptr) : 
if  ( Vos_String_Equal  ("mac_objid'  ,  var_name))  *var_p_ptr  -  (char*) 
(&prs_ptr->sv_niac_objid) ; 

if  (Vos_String_Equa1  ("my_id"  .  var_nanie))  *var_p_ptr  »  (char*) 
(&prs_ptr->sv_niy_id) : 

if  (Vos_Str1ng_Equa1  ( "1ow_dest_addr*  .  var_name))  *var_p_ptr  = 
(char*)  (&prs_ptr->sv_low_dest_addr ) ; 
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279  if  (Vos_String_Equal  ( *high_dest_addr’  .  var.name))  *var_p_ptr  - 

280  (char*)  (iprs_ptr->sv_high_dest_addr ) : 

281  if  ( Vos_String_Equa1  (■station_addr*  .  var_name))  *var_p_ptr  - 

282  (char*)  (&prs_ptr->sv_stat1on_addr) : 

283  if  ( Vos_String_Equal  ( *low_pkt_priority*  .  var_name))  *var_p_ptr  - 

284  (char*)  (&prs_ptr->sv_1ow_pkt_priority) : 

286  if  ( Vos_String_Equal  { 'h1gh_pkt_pr1or1ty’  .  var_nanie))  *var_p_ptr 

286  -  (char*)  (&prs_ptr->sv_high_pkt_priority ) ; 

287  if  ( Vos_String_Equa1  ( "arri  val_rate’  .  var_naine))  *var_p_ptr  - 

288  (char*)  (&prs_ptr->s v_arr1 va1_rate) : 

289  if  ( Vos_String_Equa1  ( 'mean_pk_len‘  .  var_naiiie))  *var_p_ptr  -  (char*) 

290  (&prs_ptr->sv_mean_pk_len) ; 

291  if  ( Vos_String_Equa1  ("async_mix*  .  var_name))  *var_p_ptr  ■  (char*) 

292  (&prs_ptr->sv_async_mix) ; 

293  if  (\/os_String_Equal  ( "mac.iciptr*  .  var_name))  *var_p_ptr  -  (char*) 

294  (&prs_ptr->sv_mac_iciptr) : 

295  if  (Vos_String_Equa1  ( 'num.addees.di st_ptr"  .  var_nanne))  *var_p_ptr  - 

296  (char*)  (&prs_ptr->sv_num_addees_d1st_ptr) : 

297  if  ( Vos_String_Equal  ( 'num.addees’  .  var_name))  *var_p_ptr  -  (char*) 

298  (&prs_ptr->sv_num_addees ) : 

299  if  ( Vos_Stri  ng_Equa1  ( *min_num_addees*  .  var_natne))  *var_p_ptr  - 

300  (char*)  (&prs_ptr->sv_ni1n_num_addees ) : 

301  if  ( Vos_String_Equal  ( "max_num_addees’  .  var_name))  *var_p_ptr  - 

302  (char*)  (&prs_ptr->sv_max_nuni_addees ) : 

303  if  ( Vos_String_Equa1  ( ''dest_addr*  .  var_name))  *var_p_ptr  •  (char*) 

304  (prs_ptr->sv_dest_addr ) ; 

306  POUT ; 

306  ) 

307  void 

308  fddi_gen_(nul  t_di  ag  () 

309  ( 

310  Packet  *pkptr.- 

311  int  pklen; 

312  int  *da_ptr: 

313  int  i.  restricted: 

314  int  pkt_prio: 

315  int  nix; 

316  FIN  (fdd1_gen_mult_diag  ()) 

317  FOUT: 

318  } 

319  void 

320  fddi_gen_mult_terminate  () 

321  1 

322  Packet  *pkptr: 

323  int  pklen; 
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324 


*da_ptr : 


i  nt 

325  int  i.  restricted; 

326  int  pkt_prio; 

327  int  nix: 

328  FIN  (fddi_gen_mult_terminate  ()) 

329  FOUT: 

330  ) 

331  Compcode 

332  fddi_gen_mu1t_init  (pr_state_pptr ) 

333  fddi_gen_mul t_state  **pr_state_pptr ; 

334  { 

335  static  VosT_Cni_Obtype  obtype  -  0PC_NIL: 

336  FIN  (fddi_gen_mult_init  (pr_state_pptr) ) 

337  if  (obtype  —  OPC.NIL) 

338  { 

339  if  ( Vos_Catmem_Register  Cproc  state  vars  (fddi_gen_mult)’. 

340  sizeof  (fddi_gen_mul t_state) .  Vos_Nop,  &obtype)  — 

341  VOSC.FAILURE) 

342  FRET  (0PC_C0MPC0DE_FAILURE) 

343  ) 

344  if  ( (*pr_state_pptr  -  (fdd1_gen_muU_state*)  Vos_Catniem_Anoc 

345  (Obtype.  1)T  —  OPC.NIL) 

346  FRET  (0PC_C0MPC0DE_FAlLURE) 

347  else 

348  { 

349  (*pr_state_pptr ) ->current_b1ock  -  0: 

350  FRET  (0PC_C0MPC0DE_SUCCESS) 

351  ) 

352  1 

353  /*  static  added  2DEC93,  on  advice  from  MIL  3,  Inc.  */ 

354  static 

355  fddi_gen_schedu1e  () 

356  1 

357  double  inter_time; 

358  /*  obtain  an  interarrival  period  according  to  the  */ 

359  /*  prescribed  distribution  */ 

360  inter_titne  =  op_di  st_outcome  ( inter_dist_ptr) : 

361  I*  schedule  the  arrival  of  next  generated  packet  */ 

362  op_intrpt_schedule_self  (op_sim_time  ()  +  inter_tinie,  0): 

363  ) 
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APPENDIX  G.  SINK  "C"  CODE: 


"fddi_sink_multpr.c" 

The  line  numbering  in  this  appendix  is  used  for  reference  within  this  thesis  only,  and 
does  not  correspond  with  that  seen  in  OPNEl^s  text  editors. 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 


/*  Process  model  C  form  file:  fdd1_s1nk_mult.pr.c  */ 

/*  Portions  of  this  file  Copyright  (C)  MIL  3,  Inc.  1992  */ 

/*  OPNET  system  definitions  */ 

^Include  <opnet.h> 

^Include  ’fdd1_s1nk_mult.pr.h* 

FSM_EXT_DECS 

/*  Header  block  */ 

/*  Globals  */ 

/*  array  format  Installed  20JAN94;  positions  0*7  represent  the  asynch 
priority  levels.  PRIORITIES  +  1  */ 

/*  represents  synch  traffic,  and  grand  totals  are  as  given  In  the 
original.  */ 


#def1ne  PRIORITIES  8  /*  20JAN94  */ 

double  fdd1_s1nk_accum_delay  -  0.0; 

double  fdd1_s1nk_accum_delay_a[PRI0RITIES  +  1]  ■  10.0,  0.0,  0.0, 

0.0,  0.0.  O.oT  0.0.  0.0,  0.0); 

Int  fdd1_s1nk_total_pkts  -  0; 

int  fdd1_s1nk_total_pkts_a[PRI0RITIES  +1]  -  {0,  0,  0,  0,  0.  0,  0. 

0.  0); 

double  fdd1_s1nk_total_b1ts  -  0.0; 

double  fdd1_s1nk_total_b1ts_a[PRI0RITIES  +1]  *  (0.0,  0.0,  0.0, 

0.0,  0.0,  0.0,  0.0.  0.0,  0.0); 

double  fdd1_s1nk_peak_delay  -  0.0; 

double  fdd1_s1nk_peak_delay_a[PRI0RITIES  +2]  -  {0.0,  0.0,  0.0, 

0.0,  0.0,  0.0,  0.0.  0.0,  0.0); 

Int  fdd1_s1nk_scalar_wr1te  -  0; 

Int  pr1_set  -  20;/*  20JAN94  */ 


/*  Externally  defined  globals.  */ 
extern  double  fdd1_t_opr  []; 
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31  /*  Attributes  fromEnvl ronraent  file.  */ 

32  double  Offered_Load;/*  12JAN94  */ 

33  double  Asynch_Offered_Load:  /*  I2JAN94  */ 


34  /*  transition  expressions  */ 

35  ^define  END_0F_SIM  op_1ntrpt_type( )  “  OPC_INTRPT_ENDSIM 


36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 


/*  State  variable  definitions  */ 
typedef  struct 
{ 


FSM_SYS_STATE 
Gshandle 
Gshandle 
Gshandle 
Gshandle 
Gshandle 
Gshandle 
)  fdd1_s1nk_mult_state: 


sv_thru_gshandle; 
s v_ra_del ay_gshandl e : 
s v_ete_del ay_gshandl e ; 
sv_thru_gshandle_a[10] ; 
sv_m_delay_gshandle_a[10] ; 
sv_ete_delay_gshandle_a[9] ; 


47  #def1ne  pr_state_ptr 
46  S1niI_Mod_State_Ptr) 

49  #def1ne  thru_gshandle 

50  ^define  m_delay_gshandle 

51  f/define  ete_delay_gshandle 

52  ^define  thru_gshandle_a 

53  ^define  m_delay_gshandle_a 

54  #def1ne  ete_delay_gshand1e_a 


( (fdd1_s1nk_mult_state*) 

pr_state_ptr->sv_thru_gshandle 
pr_state_ptr->sv_m_del ay_gshandle 
pr_state_ptr->sv_ete_delay_gshandle 
pr_state_ptr->sv_thru_gshandle_a 
pr_state_ptr->sv_m_delay_gshandle_a 
pr_state_ptr->sv_ete_delay_gshdndle_a 


55  /*  Process  model  Interrupt  handling  procedure  */ 


56 

57 

58 

59 

60 
61 
62 
63 


void 

fddi  sink  mult 
{" 

double 

Packet* 

1nt 

Id* 

double 


() 


delay.  creat_t1me: 
pkptr; 

src_addr.  my_addr; 
f rom_mac_ic1_ptr ; 
fdd1_s1nk_ttrt; 


64  FSM.ENTER  (fdd1_s1nk_mult) 

65  FSM_BL0CK_SWITCH 

66  { 

67  /* . */ 

68  /**  state  (DISCARD)  enter  executives  **/ 

69  FSM_STATE_ENTER_UNFORCED  (0.  state0_enter_exec.  "DISCARD") 

70  { 

71  /*  get  the  packet  and  the  Interface  control  Info  */ 

72  pkptr  -  op_pk_get  (op_1ntrpt_strm  ()); 

73  from_mac_1c1_ptr  -  op_1ntrpt_1c1  (); 


74  /*  20JAN94:  get  the  packet’s  priority  level,  which  */ 

75  /*  will  be  used  to  Index  arrays  of  thruput  and  delay  */ 

76  /*  computations.  */  H 

77  t*  pr1_set  -  op_pk_pr1or1ty_get  (pkptr);  doesn’t  work  here  */ 

78  op_pk_nfd_get  (pkptr.  ’prl”.  ipr1_set);/*  29JAN94  */ 

79  /*  add  In  Its  size  */ 

80  fdd1_s1nk_total_b1ts  +-  op_pk_total.s1ze_get  (pkptr); 

81  fdd1_s1nk_total_b1ts_aCpr1_set]  +-  op_pk_total_s1ze_get 

82  (pkptr);  /*  20JAN94  */ 

83  /*  determine  the  time  of  creation  of  the  packet  */ 

84  op_pk_nfd_get  (pkptr.  •cr_t1me'',  4creat_t1roe) ; 

85  /*  accumulate  delays  */ 

86  delay  -  op_s1m_t1me  ()  -  creat.time; 

87  fdd1_s1nk_accum_delay  +-  delay; 

88  fdd1_s1nk_accuffl_delay_aCpr1_set]  +-  delay;  /*  20JAN94  */ 

89  I*  keep  track  of  peak  delay  value  *! 

90  If  (delay  >  fdd1_s1nk_peak_delay) 

91  fdd1_s1nk_peak_delay  *  delay; 


92 

/* 

93 

94 

95 

/* 

96 

!* 

97 

!* 

96 

/* 

99 

100 

/* 

101 

/* 

102 

/* 

103 

/* 

104 

/* 

105 

/* 

106 

/* 

107 

108 

109 

/* 

110 

/* 

111 

/* 

112 

/* 

113 

200AN94;  keep  track  by  priority  levels  as  well  23JAN94  */ 
1f  (delay  >  fdd1_s1nk_peak_delay_a[pr1_set]) 
fdd1_s1nk_peak_delay_aCpr1_set]  -  delay; 

**★*♦♦★♦★*★★★★★★★*★***♦★**★★******★**♦***★♦★*  * / 
prIntfCOISCARO;  pri.set  Is  Xd\n*.  pri.set);  */ 

♦  ♦♦★★♦iHf******'******'*************************  *  / 

destroy  the  packet  *! 

op_pk_destroy  (pkptr); 

03FEB94:  To  convert  this  to  the  "fdd1_s1nk_l Ink”  */ 
model,  deactivate  the  ’destroy’  code,  and  activate  */ 
the  following  ’enqueue’  code.  This  is  a  first  */ 
step  toward  developing  a  LAN  bridging  structure.  */ 

-Nix  */ 

op_subq_pk_1nsert  (pr1_set.  pkptr.  0PC_QP0S_TAIL) ;  */ 

increment  packet  counter;  20JAN94  */ 
fdd1_s1nk_total_pkts++; 
fdd1_s1nk_total_pkts_a[pr1_set]++; 

if  a  multiple  of  25  packets  Is  reached,  update  stats  */ 
03FEB94:  [0]->C7]  represent  asynch  priorities  l->8.  */ 

respectively;  [8]  represents  synchronous  traffic,  *! 
and  [9]  represents  overall  asynchronous  traffic. -Nix  */ 
if  (fdd1_s1nk_total_pkts  X  1  “  0) 
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114 

115 

116 

117 

118 

119 

120 
121 
122 

123 

124 

125 

126 
127 
126 

129 

130 

131 

132 

133 

134 

135 


I 

op_stat_global_wr1te  (thru_gshandle.  fdd1_s1nk_total_b1ts  / 
op_s1ra_t1me  ()): 

op_stat_g1obal_wr1te  (thru_gshandle_a[0] , 

fdd1_s1nk_total_b1ts_aC0]  /  op_s1m_t1me( ) ) ; 
op_stat_global_wr1te  (thru_gshandle_a[l] , 
fdd1_s1nk_total_b1ts_a[13  /  op_s1ra_t1me( ) ) : 
op_stat_global_wr1te  (thru_gshandle_a[2] , 
fdd1_s1nk_total_b1ts_a[23  /  op_s1m_t1rae( ) ) ; 
op_stat_global_wr1te 

(thru_gshandle_aC3] ,fdd1_s1nk_total_b1 ts_a[3]  / 
op_s1ra_t1rae( ) ) ; 

op_stat_global_wr1te  (thru_gshandle_a[4] . 

fdd1_s1nk_total_b1ts_aC4]  /  op_s1m_t  'ne{)): 
op_stat_globa1_write  (thru_gshandle_a[5i . 

fdd1_s1nk_tota1_b1ts_a[5]  /  op_s1m_t1me( ) ) : 
op_stat_global_wr1te  (thru_gshandle_a[6] . 

fdd1_s1nk_total_b1ts_a[6]  /  op_s1ra_t1nie( ) ) ; 
op_stat_global_wr1te  (thru_gshandle_a[7] , 

fdd1_s1nk_total_b1ts_a[7]  /  op_s1m_t1me{ ) ) : 
op_stat_global_wr1te  (thru_gshandle_a[8] , 

fdd1_s1nk_total_b1ts_a[8]  /  op_s1m_t1me( ) ) ; 


136  /*  30JAN94;  gather  all  asynch  stats  Into  one  overall  figure  */ 

137  op_stat_global_wr1te  (thru_gshandle_a[9] , 

138  (fdd1_s1nk_total_b1ts_at0]  +  fdd1_s1nk_total_b1ts_a[l]  + 

139  fddi_s1nk_total_b1ts_at23  +  fdd1_s1nk_tota1_b1ts_aC3]  + 

140  fdd1_s1nk_tota1_b1ts_a[43  +  fdd1_s1nk_total_b1ts_a[53  + 

141  fdd1_s1nk_total_b1ts_aC63  +  fdd1_s1nk_total_b1ts_a[73 )  / 

142  op_s1ra_t1rae( ) ) ; 

143 

144  /*  (fddi_sink_total_b1ts  -  fdd1_sink_total_b1ts_a[83 )  /  */ 

145  /*  op_s1m_t1rae( ) ) ;  *! 


146  op_stat_g1obal_wr1te  (m_delay_gshandle.  fdd1_s1nk_accum_de1ay 

147  /  fddi_s1nk_total_pkts); 

148  op_stat_globa1_wr1te  (ra_delay_gsha'’dle_a[03 . 

149  fdd1_s1nk_accum_delay_a[03  /  fc  _s1nk_total_pkts_a[03 ) : 

150  op_stat_global_wr1te  (ra_delay_gshc  1e_a[13. 

151  fdd1_s1nk_accuni_delay_a[13  /  faGl_sink_tota1_pkts_a[13 ) : 

152  op_stat_global_wr1te  (m_delay_gshandle_a[23 . 

153  fdd1_s1nk_accum_delay_a[23  /  fdd1_s1nk_total_pkts_a[23 ) ; 

154  op_stat_global_wr1te  (m_delay_gshand1e_a[33 , 

155  fdd1_sink_accum_delay_a[33  /  fdd1_s1nk_total_pkts_a[33 ) : 

156  op_stat_global_wr1te  (ni_delay_gshandle_a[43 . 

157  fdd1_s1nk_accuni_delay_a[43  /  fdd1_s1nk_tota1_pkts_a[43 ) : 

158  op_stat_global_wr1te  (m_delay_gshandle_aC53 . 

159  fdd1_s1nk_accum_de1ay_a[53  /  fdd1_s1nk_total_pkts_a[53 ) ; 

160  op_stat_global_write  (m_delay_gshandle_a[63 , 

161  fdd1_s1nk_accuni_de1ay_a[63  /  fdd1_s1nk_total_pkts_aC63 ) ; 
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op_stat_global_wr1te  (ni_delay_gshan(ne_at7] , 

fd(l1_s1nk_accutn_delay_a[7]  /  fdd1_s1nk_tota1_pkts_aC7] ) ; 
op_stat_global_wr1te  (ni_delay_gshand1e_a[8] , 

fdd1_s1nk_accum_de1 ay_a[8]  /  fdd1_s1nk_total_pkts_a[8] ) : 

/*  30JAN94:  gather  all  asynch  stats  Into  one  figure  */ 
op_stat_global_wr1te  (m_delay_gshandle_a[9] . 

(fdd1_s1nk_accum_delay_a[0]  +  fdd1_s1nk_accura_de1ay_aCl]  + 
fdd1_s1nk_accura_delay_a[2]  +  fdd1_sink_accuni_de1ay_a[3]  + 
fdd1_s1nk_accum_delay_a[4]  +  fdd1_s1nk_accum_delay_aC5]  + 
fdd1_s1nk_accum_delay_a[6]  +  fdd1_s1nk_accum_delay_aC7] )  / 
(fdd1_s1nk_total_pkts_aC0]  +  fdd1_s1nk_total_pkts_aCl]  + 
fdd1_sink_total_pkts_aC23  +  fdd1_s1nk_total_pkts_a[3]  + 
fdd1_s1nk_total_pkts_a[4]  +  fdd1_s1nk_total_pkts_a[5]  + 
fdd1_s1nk_total_pkts_a[63  +  fdd1_s1nk_total_pkts_a[73 ) ) : 

/*  (fdd1_sink_accuni_delay  -  fddi_s1nk_accum_delay_a[83)  /  */ 

I*  (fdd1_s1nk_total_pkts  -  fdd1_sink_total_pkts_aC83 ) ) :  *! 

1 

/*  also  record  actual  delay  values  */ 

op_stat_global_wrlte  (ete_delay_gshandle.  delay); 
op_stat_global_wr1te  {ete_delay_gshandle_aCpri_set3 .  delay); 


/**  blocking  after  enter  executives  of  unforced  state.  **! 
FSM.EXIT  {I.fdd1.s1nk_rault) 

/♦*  state  (DISCARD)  exit  executives  **/ 

FSM_STAT:_EXIT_UNF0RCED  (O.  state0_ex1t_exec.  ’DISCARD*) 


/**  state  (DISCARD)  transition  processing  **! 
FSM_INIT_COND  (END_0F_SIM) 

FSM_DFLT_COND 

FSM_TEST_LOGIC  ("DISCARD’) 

FSM_TRANSIT_SWITCH 

{ 

FSM_CASE_TRANSIT  (0.  1.  statel_enter_exec .  ;) 
FSM_CASE_TRANSIT  (1.  0,  stateO_enter_exec.  ;) 


/**  state  (STATS)  enter  executives  **/ 

FSM_STATE_ENTER_UNFORCED  (1.  statel^enter_exec .  ’STATS’) 
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203  /*  At  end  of  simulation,  scalar  performance  statistics  */ 

204  /*  and  Input  parameters  are  written  out.  */ 


205 

206 
207 
206 

209 

210 
211 
212 

213 

214 

215 

216 

217 

218 

219 

220 
221 
222 

223 

224 

225 

226 

227 

228 

229 

230 

231 

232 

233 

234 

235 

236 

237 


/*  Only  one  station  needs  to  do  this  */ 

If  (!fdd1  s1nk_scalar_wr1te) 

{ 

/*  set  the  scalar  write  flag  */ 

fdd1_s1nk_scalar_wr1te  -  1; 

op_stat_scalar_wr1te  (“Mean  End-to-End  Delay  (sec.). 
Priority  1“.  fdd1_s1nk_accum_delay_a[0]  / 
fdd1_s1nk_total_pkts_a[0] ) ; 
op_stat_scalar_wr1te  (“Mean  End-to-End  Delay  (sec.). 
Priority  2“,  fdd1_s1nk_accum_deldy_a[l]  / 
fdd1_s1nk_total_pkts_aC13 ) : 
op_stat_scalar_wr1te  (“Mean  End-to-End  Delay  (sec.), 
"priority  3“.  fdd1_s1nk_accum_delay_a[2]  / 
f dd 1 _s 1 n k_tot a 1 _pkt s_a [ 2 3 ) : 
op_stat_scalar_wr1te  (“Mean  End-to-End  Delay  (sec.). 
Priority  4“.  fdd1_s1nk_accum_delay_a[33  / 
fdd1_s1 nk_total_pkts_a[33 ) ; 
op_stat_scalar_wr1te  (“Mean  End-to-End  Delay  (sec.). 
Priority  5“.  fdd1_s1nk_accum_delay_a[43  / 
fdd1_s1nk_total_pkts_a[43 ) : 
op_stat_scalar„wr1te  (“Mean  End-to-End  Delay  (sec.). 
Priority  6“.  fdd1_s1nk_accum_delay_a[53  / 
fdd1_s1 nk_total_pkts_aC53 ) ; 
op_stat_scalar_wr1te  (“Mean  End-to-End  Delay  (sec.). 
Priority  7“,  fdd1.s1nk_accum_delay_a[63  / 
fdd1_s1 nk_total_pkts.a[63 ) ; 
op_stat_sca la rewrite  (“Mean  End-to-End  Delay  (sec.), 
Priority  8“,  fdd1_s1nk_accum_delay_a[73  / 
fdd1_s1nk_total_pkts_a[73 ) ; 
op_stat_scalar_wr1te  (“Mean  End-to-End  Delay  (sec.). 
Asynchronous “ ,  (fdd1_s1nk_accura_delay  - 
fdd1_s1nk_accum_delay_aC83)  /  (fdd1_s1nk_total_pkts 
fdd1_s1nk_total_pkts_aC83) ); 


238  /*  (fddi_sink_accum_delay_a[03  *  fdd1_s1nk_accum_delay_a[13  +  */ 

239  /*  fdd1_sink_accum_delay_a[23  +  fddi_s1nk_accum_delay_a[33  +  */ 

240  /*  fdd1_sink_accum_delay_a[43  +  fdd1_s1nk_accum_delay_a[53  +  */ 

241  /*  fddi_sink_accum_delay_a[63  +  fdd1_s1nk_accum_del ay_a[73 )  /  */ 

242  /*  (fdd1_s1nk_total_pkts_aC03  +  fdd1_s1nk_total_pkts_a[13  +  */ 

243  /*  fdd1_s1nk_total_pkts_a[23  +  fdd1_s1nk_total_pkts_a[33  +  */ 

244  /*  fdd1_s1nk_total_pkts_aC43  +  fdd1_s1nk_total_pkts_a[53  +  */ 

2^  /*  fdd1_s1nk_total_pkts_a[63  +  fdd1_s1nk_total_pkts_a[73 ) ) ;  */ 

246  op_stat_scalar_wr1te  (“Mean  End-to-End  Delay  (sec.), 

247  Synchronous “ ,  fdd1_s1nk_accum_del ay_a[83  / 

248  fdd1_s1nk_total_pkts_a[83 ) ; 
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249 

250 

251 

252 

253 

254 

255 

256 

257 

258 

259 

260 


op_stat_sca1ar_wr1te  (*Mean  End-to-End  Delay  (sec.).  Total". 

fdd1_s1nk_accum_delay  /  fdd1_s1nk_total_pkts) ; 
op_stat_scalar_wr1te  ("Throughput  (bps).  Priority  1". 

fdd1_s1nk_total_b1ts_at0]  /  op_s1m_t1me  ()): 
op_stat_scalar_wr1te  ("Throughput  (bps).  Priority  2". 

fdd1_s1nk_total_b1ts_aCl]  /  op_s1ra_t1me  ()): 
op_stat_scalar_wr1te  ("Throughput  (bps).  Priority  3". 

fdd1_s1nk_total_b1ts_aC2]  /  op_slm_t1rae  ()): 
op_stat_scalar_wr1te  ("Throughput  (bps).  Priority  4". 

fdd1_s1nk_total_b1ts_a[3]  /  op_s1m_t1me  ()); 
op_stat_scalar_wr1te  ("Throughput  (bps).  Priority  5". 
fdd1_s1nk_total_b1ts_aC4]  /  op_s1m_t1me  ()); 


261 

262 

263 

264 

265 

266 

267 

268 
269 


op_stat_scalar_wr1te  ("Throughput  (bps).  Priority  6". 

fdd1_s1nk_total_b1ts_aC5]  /  op_s1ra_t1me  ()); 
op_stat_scalar_wr1te  ("Throughput  (bps).  Priority  7". 

fdd1_s1nk_total_b1ts_aC6]  /  op_s1m_t1me  ()); 
op_stat_scalar_wrlte  ("Throughput  (bps).  Priority  8". 

fdd1_s1nk_total_b1ts_aC7]  /  op_s1ni_t1me  ()); 
op_stat_scalar_wr1te  ("Throughput  (bps).  Asynchronous". 
(fdd1_s1nk_tota1_b1ts  -  fdd1_s1nk_total_b1ts_a[8] )  / 
op_s1ni_t1me  ()); 


270  /*  (fdd1_s1nk_total_b1ts_a[0]  +  fdd1_s1nk_total_b1ts_a[13  +  */ 

271  I*  fdd1_s1nk_total_b1ts_a[2]  fdd1_s1nk_total_b1ts_a[3]  +  */ 

272  /*  fdd1_s1nk_total_b1ts_aC4]  +  fdd1_s1nk_total_b1ts_a[5]  +  */ 

273  /*  fdd1_s1nk_total_b1ts_aC6]  +  fdd1_s1nk_total_b1ts_a[7])  /  */ 

274  /*  op_s1ni_t1rae  ());  */ 


275 

276 

277 

278 

279 

280 
281 
282 

283 

284 

285 

286 

287 

288 

289 

290 

291 

292 

293 

294 


tat_scalar_wr1te  ("Throughput  (bps 
dld1_s1nk_tota1_b1ts_a[8]  /  op_s1ni_ 
tat_scalar_wr1te  ("Throughput  (bps 
[ldi_s1nk_total_b1ts  /  op_s1m_t1rae 
tat_scalar_vir1te  ("Peak  End-to-End 
",  fdd1_s1nk_peak_de1ay_a[0] ) ; 

tat_sca1ar_wr1te  ("Peak  End-to-End 
".  fdd1_s1nk_peak_delay_a[l]) ; 

tat_sca1ar_wr1te  ("Peak  End-to-End 
".  fdd1_s1nk_peak_delay_a[2] ) ; 

tat_sca1ar_wr1te  ("Peak  End-to-End 
",  fdd1_s1nk_peak_delay_a[3] ) ; 

tat_scalar_wr1te  ("Peak  End-to-End 
",  fdd1_s1nk_peak_delay_a[4] ) ; 

tat_sca1ar_wr1te  ("Peak  End-to-End 
",  fdd1_s1nk_peak_delay_a[5] ) ; 

tat_scal ar_wr1te  ("Peak  End-to-End 
".  fdd1_s1nk_peak_delay_a[6] ) ; 

tat_scalar_wr1te  ("Peak  End-to-End 
",  fdd1_s1nk_peak_delay_a[7] ) ; 


),  Synchronous' 
time  ()); 

).  Total". 

()): 

Delay  (sec.). 
Delay  (sec.). 
Delay  (sec.). 
Delay  (sec. ) . 
Delay  (sec.). 
Delay  (sec.). 
Delay  (sec.). 
Delay  (sec.). 


Priority 
Priority 
Priority 
Priori ty 
Priority 
Priority 
Priority 
Priority 
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<'P_stat_scalar_wr1te  ('Peak  End-to-End  Delay  (sec.), 
Synchronous' ,  fdd1_s1nk_peak_delay_aC8] ) ; 
op_stat_scalar_wr1te  ('Peak  End-to-End  Delay  (sec.).  Overall', 
fdd1_s1nk_peak_delay) ; 

/*  Write  the  TTRT  value  for  ring  0.  This  preserves  */ 

/*  the  old  behavior  for  single-ring  simulations.  */ 

op_stat_scalar_wr1te  ('TTRT  (sec.)  -  Ring  0' ,fdd1_t_opr 

[0]): 

/*  12JAN94;  obtain  offered  load  Information  from  the  Environment  */ 

I*  file:  this  will  be  used  to  provide  abscissa  Information  that 
I*  can  be  plotted  In  the  Analysis  Editor  (see  'fdd1_s1nk'  STATS  */ 

/*  state.  To  the  user:  It's  your  Job  to  keep  these  current  In  */ 

/*  the  Environment  File.  -Nix  *! 

op_1ma_s1m_attr_get  (0PC_IHA_D0UBLE,  'total_offered_load' , 
&0ffered_Load) : 

op_1ma_s1m_attr_get  (0PC_IMA_D0UBLE.  'asynch_offered_load' . 
&Asynch_Offered_Load ) ; 


/*  I2JAN94:  write  the  total  offered  load  for  this  run  */ 
op_stat_scalar_wr1te  ('Total  Offered  Load 
(Mbps ) ' ,Offered_Load) ; 

op_stat_scalar_wr1te  ('Asynchronous  Offered  Load  (Mbps)', 
Asynch_Offered_Load ) ; 

) 

} 

/**  blocking  after  enter  executives  of  unforced  state.  **/ 

FSM_EXIT  (3.fdd1_s1nk_mult) 

/**  state  (STATS)  exit  executives  **/ 

FSM_STATE_EXIT_UNFORCED  (1.  Statel_ex1t_exec.  ’STATS') 

{ 

) 

/**  State  (STATS)  transition  processing  **/ 

FSM_TRANSIT_MISSING  (’STATS') 

/* . */ 


!**  state  (INIT)  enter  executives  **/ 

FSM_STATE_ENTER_FORCED  (2.  state2_enter_exec ,  'INIT') 

{ 

/*  get  the  gshandles  of  the  global  statistic  to  be  obtained  *! 

/*  20JAN94:  set  array  format  */ 

thru_gshandle_a[0]  -  op_stat_global_reg  ('pri  1  throughput 
(bps)' ) ; 
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359 

360 

361 
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363 

364 
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366 

367 
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378 
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thru_gshan<ne_a[l]  -  op_stat_global_reg  (‘pri  2  throughput 
(bps)*); 

thru_gshan<ne_aC2]  -  op_stat_globa1_reg  ("pri  3  throughput 
(bps)*); 

thru_gshandle_a[3]  -  op_stat_global_reg  (*pr1  4  throughput 
( bps ) * ) ; 

thru_gshandle_aC4]  -  op_stat_global_reg  (*pr1  5  throughput 
(bps)*); 

thru_gshandle_aC5]  -  op_stat_global_reg  (*pr1  6  throughput 
(bps)*); 

thru_gshandle_aC6]  -  op_stat_global_reg  (*pr1  7  throughput 
(bps)*); 

thru_gshandle_aC7]  -  op_stat_global_reg  (*pr1  8  throughput 
(bps)*); 

thru_gshandle_aC8]  -  op_stat_globa1_reg  (*synch  throughput 
(bps)*); 

thru_gshandle_aC9]  -  op_stat_global_reg  (*async  throughput 
(bps)*); 

thru_gshandle  -  op_stat_global_reg  (*total  throughput  (bps)*): 

tB_delay_gshand1e_aC0]  ■  op_stat_global_reg  (*pr1  1  mean  delay 
(sec. )* ) : 

m_delay_gshandle_a[l]  -  op_stat_global_reg  (*pr1  2  mean  delay 
(sec.  )* ) ; 

m_delay_gshandle_a[2]  -  op_stat_global_reg  (*pr1  3  mean  delay 
(sec. )* ) ; 

m_delay_gshandle_a[3]  «  op_stat_global_reg  (*pri  4  mean  delay 
(sec. )*): 

m_delay_gshandle_a[4]  -  op_stat_global_reg  (*pr1  5  mean  delay 
(sec. )*); 

m_delay_gshandle_aC5]  ■  op_stat_global_reg  (*pri  6  mean  delay 
(sec. )* ) ; 

m_delay_gshandle_a[6]  •  op_stat_global_reg  (*pri  7  mean  delay 
(sec.  )* ) ; 

m_delay_gshandle_a[7]  -  op_stat_global_reg  (*pr1  6  mean  delay 
(sec.  )* ) ; 

m_delay_gshandle_a[8]  •  op_stat_global_reg  (*synch  mean  delay 
(sec.  )* ) : 

m_delay_gshandle_aC9]  •  op_stat_global_reg  (*async  mean  delay 
(sec. )  * ) ; 

m_del ay_gshandle  -  op_stat_global_reg  (*total  mean  delay 
(sec.  )* ) ; 

ete_delay_gshandle_aC0]  -  op_stat_global_reg  (*pr1  1  end-to-end 
delay  (sec.)*): 

ete_delay_gshandle_aCl]  -  op_stat_global_reg  (*pri  2  end-to-end 
delay  (sec.)*); 

ete_delay_gshandle_aC2]  -  op_stat_global_reg  (*pr1  3  end-to-end 
delay  (sec.)*); 

ete_delay_gshandle_a[3]  -  op_stat_global_reg  (*pr1  4  end-to-end 
delay  (sec.)*); 
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ete_delay_gshandle_a[4]  -  op_stat_globa1_reg  Cprl  5  end-to-end 
delay  (sec.)'): 

ete_delay_gshandle_a[5]  -  op_stat_global_reg  ("pri  6  end-to-end 
delay  (sec.)'); 

ete_delay_gshand1e_aC6]  -  op_stat_global_reg  Cprl  7  end-to-end 
delay  (sec.)'): 

ete_del ay_gshandle_a[7]  -  op_stat_global_reg  Cpri  8  end-to-end 
delay  (sec.)'): 

ete_delay_gshandle_aC8]  -  op,stat_global_reg  ('synch  end-to-end 
delay  (sec.)'): 

ete_delay_gshandle  -  op_stat_global_reg  ('total  end-to-end 
delay  (sec.)'): 

} 


399  !**  state  (INIT)  exit  executives  **! 

400  FSM_STATE_EXIT_FORCEO  (2.  state2_ex1 t.exec .  'INIT') 

401  { 

402  } 

403  /**  state  (INIT)  transition  processing  **/ 

404  FSM_INIT_COND  (END_0F_SIM) 

405  FSM  DFLT_C0ND 

406  FSM_TEST_L0GIC  ('INIT') 


407  FSM  TRANSIT.SWITCH 

408  ( 

409  FSM_CASE_TRANSIT  (0.  1.  statel_enter_exec,  :) 

410  FSM_CASE_TRANSIT  (1.  0,  stateO_enter_exec ,  ;) 

411  ) 

412  /* . */ 

413  ) 


414  FSM.EXIT  (2.fdd1_s1nk_rault) 

415  ) 


416  void 

417  fdd1_s1nk_mult_svar  (prs_ptr . var_name, var_p_ptr ) 

418  fdd1_s1nk_mult_state  *prs_ptr; 

419  char  *var_nanie,  **var_p_ptr: 

420  { 

421  FIN  (fdd1_s1nk_mult_svar  (prs_ptr)) 

422  *var_p_ptr  -  V0S_NIL; 

423  If  (Vos_Str1ng_Equal  ( 'thru_gshandle'  ,  var_name)) 

424  *var_p_ptr  -  (char  *)  (&prs_ptr->sv_thru_gshandle) ; 

425  1f  (Vos_Str1ng_Equal  ( 'ni_del ay_gshandle"  ,  var_name)) 

426  *var_p_ptr  -  (char  *)  (&prs_ptr->sv_n)_delay_gshandle) : 

427  if  ( Vos_Str1ng_Equal  ('ete_delay_gshandle'  ,  var_name)) 

428  *var_p_ptr  -  (char  *)  (&prs_ptr->sv_ete_delay_gshand1e) : 
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if  (Vos_Str1ng_Equal  ( ■thru_gshandle_a*  ,  var_name)) 
*var_p_ptr  -  (char  *)  (prs_ptr->sv_thru_gshancne_a) : 
if  {VosIstring_Equal  ( *m_delay_gshandle_a*  .  var.name)) 
*var_p_ptr  -  (char  *)  (prs_ptr->sv_m_delay_gshandle_a) : 
if  (VosIstr1ng_Equal  ( "ete.delay.gshandle.a*  .  var.name)) 
*var_p_ptr  -  (char  *)  (prs_ptr->sv_ete_del ay_gshandl€_a ) ; 
FOUT; 

1 


void 

fdd1_s1nk_mul t_d1ag  () 


{ 

double  delay,  creat_t1me: 

Packet*  pkptr: 

int  src_addr,  my.addr: 

Id*  from_mac_1c1_ptr : 

double  fdd1_s1nk_ttrt: 


FIN  (fdd1_s1nk_mult_d1ag  ()) 
FOUT; 

} 


voi  d 

fddi  s1nk_mult_terni1nate  () 
l” 

double  delay,  creat.time; 

Packet*  pkptr; 

int  src_addr,  ray.addr; 

Ici*  from_mac_ici_ptr; 

double  fdd1_sink_ttrt; 

FIN  (fddi_sink_mult_terminate  ()) 
FOUT; 

) 


Compcode 

fddi_sink_mult_init  (pr_state_pptr) 

fdd1_sink_mult_state  **pr_state_pptr ; 

I 

static  VosT_Cni_Obtype  obtype  -  OPC.NIL; 

FIN  (fddi_sink_mult_init  (pr_state_pptr) ) 

if  (obtype  —  0PC_NIL) 
i 

if  (Vos_Catmetn_Register  ("proc  state  vars  (fddi_sink_mult) " , 
sizeof  (fddi_sink_mult_state) ,  Vos_Nop,  &obtype)  — 
VOSC.FAILURE) 

470  FRET  (0PC_C0MPC0DE_FAILURE) 

471  } 
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472  If  ( (*pr_state_pptr  -  (fdd1_s1ntc_iBult_state*)  Vos  Catmem  Alloc 

473  (obtype.  D)  —  OPC.NIL) 

474  FRET  (0PC_C0MPC00E_FAILURE) 

475  else 

476  { 

477  (*pr_state_pptr)->current_block  -  4; 

478  FRET  {0PC_C0MPC0DE_SUCCESS) 

479  } 

480  } 


APPENDIX  H.  ENVIRONMENT  FILE  FOR 


50-STATION  MULTICAST  CAPABLE  FDDI  LAN 


#  fddlBOmult.ef 

#  sample  simulation  configuration  file  for  fddi  example  model 
it  50  station  network  with  multiple  addressing  capability 

it***  Attributes  related  to  loading  used  by  •fddi_gen*  *** 

it  station  addresses 
*.*.f0.mac.stat1on_address:  0 
*.*.fl.mac.stat1on_address:  1 
*.*.f2.mac.stat1on_address:  2 
*.*.f3.mac.stat1on_address:  3 
*.*.f4.mac.stat1on_address:  4 
*.*.f5.mac.station_address:  5 
*.*.f6.mac.stat1on_address:  6 
*.*.f7 .mac.stat1on_address:  7 
*.*.f8.mac.stat1on„address:  8 
*.*.f9.mac.stat1on_address:  9 
*.*,fl0.mac.stat1on_address:  10 
*.*.fll.mac.stat1on_address:  11 
*.*.fl2.mac.stat1on.address:  12 
*.*,fl3.mac.stat1on.address:  13 
*.*.fl4.mac.station_address;  14 
*.*.fl5.mac.stat1on_address:  15 
*.*.fl6.mac.stat1on_ad0ress:  16 
*.*.fl7 .mac.stat1on_address:  17 
*.*.fl8.mac.stat1on_address;  18 
*.*.fl9.mac.stat1on_address;  19 
*.*.f20.mac.stat1on_address:  20 
*.*.f21 .mac.station_address;  21 
*.*.f22.mac.station_address:  22 
*.*.f23.mac.stat1on_address:  23 
*.*.f24.mac.station_address :  24 
*.*.f25.mac.stat1on_address:  25 
*.*.f26.mac.station_address :  26 
*.*.f27 .mac.station_address:  27 
*.*.f28.mac.station_address:  28 
*.*.f29.mac.station_address:  29 
*.*.f30.mac.stat1on_address:  30 
*.*.f31.mac.station_address:  31 
*.*.f32.mac.station_address:  32 
*.*.f33.mac.station_address;  33 
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*.*.f34.tiiac.stat1on_address:  34 
*.*.f35.raac.stat1on_address:  35 
*.*.f36.niac.stat1on_address:  36 
*.*.f37.raac.stat1on_address;  37 
*.*.f38.raac.stat1on_address:  38 
*.*.f39.mac.station_address:  39 
*.*.f40.raac.stat1on_address:  40 
*.*.f41.raac.stat1on_address;  41 
*.*.f42.mac.stat1on_address:  42 
*.*.f43.mac.station_address:  43 
*.*.f44.mac.station_address:  44 
*.*.f45.mac.stat1on_address:  45 
*.*.f46.mac.stat1on_address:  46 
*.*.f47.raac.stat1on_address:  47 
*.*.f48.mac.stat1on_address:  48 
*.*.f49.mac.stat1on_address :  49 

mac. r1ng_1d  :0 

y/  Range  number  of  stations  that  may  recleve  this  packet  If  more 

#  than  one  Is  designated  (model  defaults  are  both  1) 

#  Note  that  the  code  does  not  allow  the  originating  station  to 

#  address  a  packet  to  Itself,  so  max_num_addees  Is  less  than 


#  the  number  of  stations. 

•*.*.nc_src.m1n  num  addees*  :  1 

•*.*.11c_src.max  num  addees*  :  1 

destination  addresses  for  random  message  generation 
•*.*.nc_src.low  dest  address*  :  0 

**.*.nc_src.h1gh  dest  address*  :  49 

#  **.f0.11c_src.low  dest  address*  :  0 

#  **.f0.11c_src.h1gh  dest  address*  :  49 


if  range  of  priority  values  that  can  be  assigned  to  packets:  FDDI 
if  standards  allow  for  8  priorities  of  asynchronous  traffic.  MIL3’s 
if  original  mode!  Is  modified  to  allow  each  station  to  generate 
if  multiple  priorities,  within  a  specified  range.  (Note  that  while 
if  research  literature  refers  to  asynchronous  priorities  ranging 
if  from  1  to  8,  the  corresponding  numbering  here  Is  0  to  7,  In 
if  keeping  with  the  C  language  array  element  numbering  convention.) 
’*.*.llc_src.h1gh  pkt  priority*  :  7 

**.*.llc_src.low  pkt  priority*  :  0 

if  arrival  rate(frames/sec) ,  and  message  size  (bits)  for  random 
if  message  generation  at  each  station  on  the  ring. 

"*.*.*. arrival  rate*  :  750 

**.*.*. mean  pk  length"  :  1000 

if  These  are  the  synchronus  transmitters 
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**.fO.*. arrival  rate*  :  6000 

■*,f0.*.mean  pk  length*  :  512 

**.f5.*. arrival  rate*  :  6000 

**.f5.*.mean  pk  length*  512 
**.fl0.*. arrival  rate*  :  6000 

**.fl0.*.raean  pk  length*  :  512 

**.fl5.*. arrival  rate*  :  6000 

**.fl5.*.mean  pk  length*  :  512 

**.f20.*. arrival  rate*  :  60000 

**.f20.*.mean  pk  length*  :  512 

**.f25.*. arrival  rate*  :  6000 

**.f25.*.mean  pk  length*  :  512 

**.f30.*. arrival  rate*  :  6000 

**.f30.*.raean  pk  length*  :  512 

**.f35.*. arrival  rate*  :  6000 

**.f35.*.mean  pk  length*  :  512 

**.f40.*. arrival  rate*  ;  6000 

**.f40.*.raean  pk  length*  ;  512 

**.f45.*. arrival  rate*  :  60000 

**.f45.*.mean  pk  length*  ;  512 


#  120EC93:  total  offered  load  Is  the  sum  of  all  stations’ 

#  loads  (Mbps).  Compute  this  by  hand;  this  value  Is  used  In 

#  the  sink  process  model  for  generating  scalar  plots  where 

#  offered  load  Is  the  abscissa. 

total_offered_load  :  60.72 

asynch_offered_load  :  30.00 

#  set  the  proportion  of  asynchronous  traffic 

#  a  value  of  1.0  Indicates  all  asynchronous  traffic 

**.*.*. async_m1x*  ;  1.0 

**.f0.*.async_m1x*  :  0.0 
**.f5.*.async_m1x*  :  0.0 
**.fl0.*.async_m1x*  :  0.0 

'♦.fl5.*.async_m1x*  ;  0.0 

**.f20.*.async_m1x*  :  0.0 

■*.f25.*.async_m1x*  :  0.0 

**.f30.*.async_m1x*  :  0.0 

’*.f35.*.async_ra1x*  :  0.0 

■*.f40.*.async_m1x*  :  0.0 

"*.f45.*.async_m1x*  :  0.0 

#***  Ring  configuration  attributes  used  by  *fdd1_raac*  *** 

#  allocate  percentage  of  synchronous  bandwidth  to  each  station 

#  this  value  should  not  exceed  1  for  all  stations  combined;  OPNET 

#  does  not 

#  enforce  this;  01FEB94:  this  must  be  less  than  1;  see  equation  below 

**.*. mac. sync  bandwidth*  ;  0.0 
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•*.fO. mac. sync  bandwidth" 
•*.f5. mac. sync  bandwidth* 
mac. sync  bandwidth* 
**.fl5. mac. sync  bandwidth* 
**.f20. mac. sync  bandwidth* 
**.f25. mac. sync  bandwidth* 
’*.f30. mac. sync  bandwidth* 
**.f35. mac. sync  bandwidth* 
**.f40. mac. sync  bandwidth* 
**.f45. mac. sync  bandwidth* 


.09358 

.09358 

.09358 

.09358 

.09358 

.09358 

.09358 

.09358 

.09358 

.09358 


#  Target  Token  Rotation  Time  (one  half  of  maximum 

#  synchronous  response  time) 

**.*.mac.T_Req*  :  .0107 


Index  of  the  station  which  Initially  launches  the  token 
'spawn  station*:  0 

^  Delay  Incurred  by  packets  as  they  traverse  a  station’s 

#  ring  Interface  (see  Powers,  p.  351  for  a  discussion 

#  of  this  (Powers  gives  lusec.  but  60.0e*08  agrees  with 

#  Oykeman  &  Bux) 

stat1on_latency:  60.0e*08 


Propagation  Delay  separating  stations  on  the  ring. 
prop_delay;  5.085e*06 

#  Simulation  related  attributes 


#  Token  Acceleration  Mechanism  enabling  flag. 

y/  It  1s  reccomended  that  this  mechanism  be  enabled  for  most 

#  situations 

accelerate_token:  1 

seed:  10 

#  Run  control  attributes 


duration: 
verbose_s1m: 
upd_int: 
os_file: 
ov_fi le: 

y/  Opnet  Debugger  (odb) 
yy  debug: 


.5 

TRUE 

.1 

fdd150mult 

fdd150mult 

enabling  attribute 
TRUE 
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APPENDIX  I.  CONVENTIONS 

One  of  the  purposes  of  this  report  is  that  it  will  be  used  both  as  a  teaching  tool  and 
a  springboard  for  future  researchers  and  assessors  of  fiber  optic  netwoilc  simulations 
implementing  OPNET*.  Throughout  the  writing  of  this  report,  the  author  has  kept  tlM^se 
goals  in  sight  and  the  resulting  narrative  contains  technical  st^istic  conventions  in  keeping 
with  the  projected  use  of  diis  material  in  a  teaching,  reference,  and  research  environmem 
These  conventions,  inq)lemented  in  the  narrative  portion  of  this  report  only,  are  briefly 
described  here. 

All  excerpted  programming  code  fir^ents  are  isolated  on  their  own  lines  within  the 
text  and  highlighted  by  a  standard  san*ser1f  font.  Variable  names,  fiinction  names, 
and  names  of  programming  objects  referred  to  within  the  text  of  the  report  are  also 
highlighted  in  this  manner,  with  a  standard  san*ser1f  font.  Messages  fi’om  the 
computer  or  responses  to  be  made  to  computer  queries  are  set  off  in  double  quotes  and  a 
"bold  standard  san-serlf  font."  Single  keystrokes  are  highlighted  in  capitalized 
italics,  (e.g.  <CTRL+S>),  while  parameters  are  also  set  off  in  the  same  nuumer  (e.g. 
<number  of  nodes>). 
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APPENDIX  J.  GLOSSARY 


BONeS* 

CDL 

DSPO 

Environment  file 


FDDILAN 

MAC 

OPNET* 

THT 

TRT 

TTRT 


Block  Oriented  Network  Simulator 

Common  Data  Link 

Defense  Support  Project  OfBce 

A  command  file  containing  descriptors  and  values 

utilized  by  a  system  to  define  the  operating 

parameters.  Sometimes  this  file  is  refiared  to  as  the 

"configuration  file." 

Fiber  l^stributed  Data  Imerfiice  Local  Area  Network 

Medium  Access  Control 

Optimized  Networic  Engineering  Tod 

Token  Holding  Tuner 

Token  Rotation  Timer 

Target  Token  Rotation  Tinw 
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